* 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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|