[patch]Add a new reboot method

[patch]Add a new reboot method

[Chen, Huacai]

[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]

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>

 


[-- Attachment #1.2: Type: text/html, Size: 2255 bytes --]

[-- Attachment #2: new_reboot_method.patch --]
[-- Type: application/octet-stream, Size: 786 bytes --]

diff -r 672c09aad49d xen/arch/x86/shutdown.c
--- a/xen/arch/x86/shutdown.c	Tue May 20 14:50:45 2008 +0100
+++ b/xen/arch/x86/shutdown.c	Thu Feb 14 08:25:45 2008 +0800
@@ -228,6 +228,14 @@ void machine_restart(void)
 
     if ( reboot_thru_bios <= 0 )
     {
+        /*Using port 0xcf9 is a new reboot method, in many case it is more efficient than keyboard controller method*/
+        /*Step 1, soft way, write 0x06 to port 0xcf9*/
+        outb(0x6, 0xcf9);
+        /*Step 2, hard way, if soft way fails, write 0x0a, 0x0e to 0xcf9 to port 0xcf9*/
+        outb(0xa, 0xcf9);
+        outb(0xe, 0xcf9);
+
+        /*If 0xcf9 method fails, try other methods, e.g. keyboard controller and triple fault*/
         for ( ; ; )
         {
             /* Pulse the keyboard reset line. */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [patch]Add a new reboot method

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]

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>
>  
> 



[-- Attachment #1.2: Type: text/html, Size: 1197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [patch]Add a new reboot method

[Alan Cox]

> 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

Re: [patch]Add a new reboot method

[Jan Beulich]

>>> 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

Re: [patch]Add a new reboot method

[Alan Cox]

> 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.

Re: [patch]Add a new reboot method

[Keir Fraser]

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

Re: [patch]Add a new reboot method

[Keir Fraser]

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

RE: [patch]Add a new reboot method

[Chen, Huacai]

>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.

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

Re: [patch]Add a new reboot method

[Jan Beulich]

>>> 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

Re: [patch]Add a new reboot method

[Keir Fraser]

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

Re: [patch]Add a new reboot method

[Alan Cox]

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

Re: [patch]Add a new reboot method

[Keir Fraser]

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

Re: [patch]Add a new reboot method

[Alan Cox]

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

Re: [patch]Add a new reboot method

[Keir Fraser]

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

Re: [patch]Add a new reboot method

[Keir Fraser]

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

Re: [patch]Add a new reboot method

[Alan Cox]

> 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.

Re: [patch]Add a new reboot method

[Jan Beulich]

>>> 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