Re: [tip:x86/urgent] [PATCH] x86: Try the BIOS reboot method before the PCI reboot method

[Ingo Molnar]

* tip-bot for Ingo Molnar <tipbot@xxxxxxxxx> wrote:

> Commit-ID:  f042310bf8a846bcf21012ffee78d9eb562a7fa4
> Gitweb:     http://git.kernel.org/tip/f042310bf8a846bcf21012ffee78d9eb562a7fa4
> Author:     Ingo Molnar <mingo@xxxxxxxxxx>
> AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
> Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
> CommitDate: Mon, 14 Apr 2014 13:13:30 +0200
> 
> [PATCH] x86: Try the BIOS reboot method before the PCI reboot method
> 
> Steve reported a reboot hang and bisected it back to this commit:
> 
>   a4f1987e4c54 x86, reboot: Add EFI and CF9 reboot methods into the default list
> 
> He heroically tested all reboot methods and found the following:
> 
>   reboot=t       # triple fault                  ok
>   reboot=k       # keyboard ctrl                 FAIL
>   reboot=b       # BIOS                          ok
>   reboot=a       # ACPI                          FAIL
>   reboot=e       # EFI                           FAIL   [system has no EFI]
>   reboot=p       # PCI 0xcf9                     FAIL
> 
> And I think it's pretty obvious that we should only try 0xcf9 as a
> last resort - if at all.
> 
> The other observation is that (on this box) we should never try
> the PCI reboot method, but close with either the 'triple fault'
> or the 'BIOS' (terminal!) reboot methods.
> 
> Thirdly, CF9_COND is a total misnomer - it should be something like
> CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...
> 
> So this patch fixes the worst problems:
> 
>  - it orders the actual reboot logic to follow the reboot ordering
>    pattern - it was in a pretty random order before for no good
>    reason.
> 
>  - it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and
>    BOOT_CF9_SAFE flags to make the code more obvious.
> 
>  - it tries the BIOS reboot method before the PCI reboot method.
>    (Since 'BIOS' is a terminal reboot method resulting in a hang
>     if it does not work, this is essentially equivalent to removing
>     the PCI reboot method from the default reboot chain.)
> 
>  - just for the miraculous possibility of terminal (resulting
>    in hang) reboot methods of triple fault or BIOS returning
>    without having done their job, there's an ordering between
>    them as well.
> 
> Reported-and-bisected-and-tested-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> Cc: Li Aubrey <aubrey.li@xxxxxxxxxxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Cc: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
> Link: http://lkml.kernel.org/r/20140404064120.GB11877@xxxxxxxxx
> Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>

So I rebased the patch Steve tested as-is and only fixed the patch 
description and some comments in the code, preserving Steve's testing 
status, and propagated it into x86/urgent.

I've added this description that tries to describe the new/old logic:

> + * To the best of our knowledge Windows compatible x86 hardware expects
> + * the following on reboot:
>   *
>   * 1) If the FADT has the ACPI reboot register flag set, try it
>   * 2) If still alive, write to the keyboard controller
>   * 3) If still alive, write to the ACPI reboot register again
>   * 4) If still alive, write to the keyboard controller again
>   * 5) If still alive, call the EFI runtime service to reboot
> + * 6) If no EFI runtime service, call the BIOS to do a reboot
>   *
> + * We default to following the same pattern. We also have
> + * two other reboot methods: 'triple fault' and 'PCI', which
> + * can be triggered via the reboot= kernel boot option or
> + * via quirks.
> + *
> + * This means that this function can never return, it can misbehave
> + * by not rebooting properly and hanging.

If this is inaccurate (or undesirable, or fails to match the fine 
code) then please object.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/