Hi, Keir, New chipsets support a new reboot method by writing port 0xcf9, sometimes this is more efficient than "keyboard controller reboot" and "triple fault reboot". This patch add this new method and use it as a preferable one. Signed-off-by: Huacai Chen <huacai.chen@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Is it really a good idea to go poking an arbitrary I/O port without some kind of probing for its purpose? Do we even care about having a more efficient reboot method when the current methods are surely all sub-second already? -- Keir On 29/5/08 10:20, "Chen, Huacai" <huacai.chen@intel.com> wrote:> Hi, Keir, > > New chipsets support a new reboot method by writing port 0xcf9, sometimes this > is more efficient than ³keyboard controller reboot² and ³triple fault reboot². > This patch add this new method and use it as a preferable one. > > Signed-off-by: Huacai Chen <huacai.chen@intel.com> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> New chipsets support a new reboot method by writing port 0xcf9,Some new chipsets. What 0xcf9 does to others is undefined.> sometimes this is more efficient than "keyboard controller reboot" and > "triple fault reboot". This patch add this new method and use it as a > preferable one.Who cares ? Since when has the number of microseconds per reboot been remotely relevant. It simply isn''t a performance critical path. Besides which you properly need to use the ACPI power off method on a newer chipset anyway. (And I would note if Intel really thought power off efficiency was important then they wouldn''t have invented ACPI...) Alan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Alan Cox <alan@lxorguk.ukuu.org.uk> 29.05.08 12:26 >>> >> New chipsets support a new reboot method by writing port 0xcf9, > >Some new chipsets. What 0xcf9 does to others is undefined. > >> sometimes this is more efficient than "keyboard controller reboot" and >> "triple fault reboot". This patch add this new method and use it as a >> preferable one. > >Who cares ?There really is some point here I think, though so far I''ve not seen Xen to be affected: Linux post 2.6.22 (iirc) fails to reboot my Dell Precision 490 correctly, I have to force it to use the CF9 method. I tried looking into the changes that got made in that area, but wasn''t able to (spend enough time to) pin-point the problem so far. But I also agree to you and Keir that blindly writing to a port is no good idea. It should at least be assured that hardware supports this. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> to be affected: Linux post 2.6.22 (iirc) fails to reboot my Dell Precision > 490 correctly, I have to force it to use the CF9 method. I tried looking > into the changes that got made in that area, but wasn''t able to (spend > enough time to) pin-point the problem so far.You might want to boot a 32bit kernel and try acpi=off, if that does the trick then its (another) ACPI bug and the cf9 is red herring ?> But I also agree to you and Keir that blindly writing to a port is no good > idea. It should at least be assured that hardware supports this.Which takes us back to ACPI. If 0xcf9 is the correct process the ACPI method should use it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 12:49, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:>> to be affected: Linux post 2.6.22 (iirc) fails to reboot my Dell Precision >> 490 correctly, I have to force it to use the CF9 method. I tried looking >> into the changes that got made in that area, but wasn''t able to (spend >> enough time to) pin-point the problem so far. > > You might want to boot a 32bit kernel and try acpi=off, if that does the > trick then its (another) ACPI bug and the cf9 is red herring ? > >> But I also agree to you and Keir that blindly writing to a port is no good >> idea. It should at least be assured that hardware supports this. > > Which takes us back to ACPI. If 0xcf9 is the correct process the ACPI > method should use it.One issue here is that Xen itself does not support the ACPI reboot method. It would be easy for Xen to do so since the reset register is probed via a fixed entry in the FADT. I would very much like a patch to add support for this -- far more than this 0xcf9 hack! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 13:18, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:>> Which takes us back to ACPI. If 0xcf9 is the correct process the ACPI >> method should use it. > > One issue here is that Xen itself does not support the ACPI reboot method. > It would be easy for Xen to do so since the reset register is probed via a > fixed entry in the FADT. I would very much like a patch to add support for > this -- far more than this 0xcf9 hack!Actually it looks like Linux does not support ACPI reboot either. acpi_reboot() in the kernel is a no-op isn''t it? Perhaps supporting it does more harm than good for compatibility? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Since when has the number of microseconds per reboot been remotely >relevant. It simply isn''t a performance critical path. Besides whichyou>properly need to use the ACPI power off method on a newer chipsetanyway. I use "more efficient" to mean that sometimes other methods may fail, but this one doesn''t, have nothing to do with "performance critical". Yes, I found that 0xcf9 is mostly used in BIOS code rather than OS code, This patch lacks enough consideration. --Huacai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Alan Cox <alan@lxorguk.ukuu.org.uk> 29.05.08 13:49 >>> >> to be affected: Linux post 2.6.22 (iirc) fails to reboot my Dell Precision >> 490 correctly, I have to force it to use the CF9 method. I tried looking >> into the changes that got made in that area, but wasn''t able to (spend >> enough time to) pin-point the problem so far. > >You might want to boot a 32bit kernel and try acpi=off, if that does the >trick then its (another) ACPI bug and the cf9 is red herring ?As Keir also pointed out, there''s no ACPI involved in rebooting. I also did verify (in a 32-bit kernel) that it''s the keyboard boot sequence that causes the machine to hang. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 14:09, "Jan Beulich" <jbeulich@novell.com> wrote:>> You might want to boot a 32bit kernel and try acpi=off, if that does the >> trick then its (another) ACPI bug and the cf9 is red herring ? > > As Keir also pointed out, there''s no ACPI involved in rebooting. I also > did verify (in a 32-bit kernel) that it''s the keyboard boot sequence that > causes the machine to hang.ACPI *can* be involved in rebooting though, via FADT''s RESET_REGISTER. Question is: why does Linux ignore this reboot method? I expect there is a reason. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> As Keir also pointed out, there''s no ACPI involved in rebooting. I also > did verify (in a 32-bit kernel) that it''s the keyboard boot sequence that > causes the machine to hang.Ah I didn''t realise you meant through Xen - in which case you also probably need to support ACPI reboot. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 29 May 2008 14:30:04 +0100 Keir Fraser <keir.fraser@eu.citrix.com> wrote:> On 29/5/08 14:09, "Jan Beulich" <jbeulich@novell.com> wrote: > > >> You might want to boot a 32bit kernel and try acpi=off, if that does the > >> trick then its (another) ACPI bug and the cf9 is red herring ? > > > > As Keir also pointed out, there''s no ACPI involved in rebooting. I also > > did verify (in a 32-bit kernel) that it''s the keyboard boot sequence that > > causes the machine to hang. > > ACPI *can* be involved in rebooting though, via FADT''s RESET_REGISTER. > Question is: why does Linux ignore this reboot method?It doesn''t. Well at the least upstream version doesn''t. We default to keyboard currently but that probably wants reconsidering for modern systems. Alan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Alan Cox <alan@lxorguk.ukuu.org.uk> 29.05.08 16:49 >>> >> As Keir also pointed out, there''s no ACPI involved in rebooting. I also >> did verify (in a 32-bit kernel) that it''s the keyboard boot sequence that >> causes the machine to hang. > >Ah I didn''t realise you meant through Xen - in which case you also >probably need to support ACPI reboot.No, as I said earlier - under Xen I do *not* have this problem, it''s only the native kernel that got broke. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 15:59, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:>> ACPI *can* be involved in rebooting though, via FADT''s RESET_REGISTER. >> Question is: why does Linux ignore this reboot method? > > It doesn''t. Well at the least upstream version doesn''t. We default to > keyboard currently but that probably wants reconsidering for modern > systems.Well, I have to disagree. Looks to me like ACPI reboot is supposed to be implemented by acpi_reboot() and looking at 2.6.26-rc4 that function is still stubbed out. Am I missing something? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 29 May 2008 16:49:46 +0100 Keir Fraser <keir.fraser@eu.citrix.com> wrote:> On 29/5/08 15:59, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote: > > >> ACPI *can* be involved in rebooting though, via FADT''s RESET_REGISTER. > >> Question is: why does Linux ignore this reboot method? > > > > It doesn''t. Well at the least upstream version doesn''t. We default to > > keyboard currently but that probably wants reconsidering for modern > > systems. > > Well, I have to disagree. Looks to me like ACPI reboot is supposed to be > implemented by acpi_reboot() and looking at 2.6.26-rc4 that function is > still stubbed out. Am I missing something?My fault. I was looking in the tree I run not the upstream tree. We''ve had patches available for it since mid 2007. Looks like they got stuck somewhere around Andi Kleen. The original thread seems to be this one: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg06145.html although it doesn''t appear to check the fadt hdr rev is > 1 now I look harder. Looks easy enough to try in Xen, and perhaps that would also meet Huacai''s needs ? Alan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 17:01, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:> The original thread seems to be this one: > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg06145.html > > although it doesn''t appear to check the fadt hdr rev is > 1 now I look > harder. Looks easy enough to try in Xen, and perhaps that would also meet > Huacai''s needs ?I''ll be happy to give it a spin in Xen if someone (Huacai?) does the port. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/5/08 17:01, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:> My fault. I was looking in the tree I run not the upstream tree. We''ve > had patches available for it since mid 2007. Looks like they got stuck > somewhere around Andi Kleen. > > The original thread seems to be this one: > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg06145.html > > although it doesn''t appear to check the fadt hdr rev is > 1 now I look > harder.It doesn''t need to check the FADT rev by the way, since support is detected via a fixed feature flag, which is a field supported right the way back to FADT rev 1 format. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel