From: Ingo Molnar <mingo@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Li, Aubrey" <aubrey.li@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: [PATCH] x86: Try the BIOS reboot method before the PCI reboot method
Date: Fri, 4 Apr 2014 08:41:20 +0200 [thread overview]
Message-ID: <20140404064120.GB11877@gmail.com> (raw)
In-Reply-To: <20140403104721.5f6c32b6@gandalf.local.home>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 03 Apr 2014 07:10:47 -0700
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> > Could you tell which of these modes work on your box:
Basically my thinking is that the patch should be reverted, if my fix
below does not work.
I distilled your test results into:
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. For some reason the 0xcf9 reboot method got
marked 'safe' - why is that? If only pci_direct_probe() had funny
extra lines /* like this */ ...
The other observation is that (on this box) we should try the 'BIOS'
method before the PCI method.
Thirdly, CF9_COND is a total misnomer - it should be something like
CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...
[ Plus all the BOOT_ flags are total misnomers as well, why aren't
they named REBOOT_ ...? ]
Anyway, the patch below 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.
Only build tested.
Alternatively we could just use the following reboot order:
* 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 still alive, force a triple fault
I.e. eliminate the 'PCI' and 'BIOS' methods from our default sequence,
as both are documented as being able to hang some boxes.
Thanks,
Ingo
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 654b465..527dbcb 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -114,8 +114,8 @@ EXPORT_SYMBOL(machine_real_restart);
*/
static int __init set_pci_reboot(const struct dmi_system_id *d)
{
- if (reboot_type != BOOT_CF9) {
- reboot_type = BOOT_CF9;
+ if (reboot_type != BOOT_CF9_FORCE) {
+ reboot_type = BOOT_CF9_FORCE;
pr_info("%s series board detected. Selecting %s-method for reboots.\n",
d->ident, "PCI");
}
@@ -468,10 +468,15 @@ void __attribute__((weak)) mach_reboot_fixups(void)
* 6) If still alive, write to the PCI IO port 0xCF9 to reboot
* 7) If still alive, inform BIOS to do a proper reboot
*
- * If the machine is still alive at this stage, it gives up. We default to
- * following the same pattern, except that if we're still alive after (7) we'll
- * try to force a triple fault and then cycle between hitting the keyboard
- * controller and doing that
+ * If the machine is still alive at this stage, it gives up.
+ *
+ * We default to following the same pattern, except that we try
+ * (7) [BIOS] before (6) [PCI], and we add 8): try to force a
+ * triple fault and then cycle between hitting the keyboard
+ * controller and doing that.
+ *
+ * This means that this function can never return, it can misbehave
+ * by not rebooting properly and hanging.
*/
static void native_machine_emergency_restart(void)
{
@@ -492,6 +497,11 @@ static void native_machine_emergency_restart(void)
for (;;) {
/* Could also try the reset bit in the Hammer NB */
switch (reboot_type) {
+ case BOOT_ACPI:
+ acpi_reboot();
+ reboot_type = BOOT_KBD;
+ break;
+
case BOOT_KBD:
mach_reboot_fixups(); /* For board specific fixups */
@@ -509,43 +519,29 @@ static void native_machine_emergency_restart(void)
}
break;
- case BOOT_TRIPLE:
- load_idt(&no_idt);
- __asm__ __volatile__("int3");
-
- /* We're probably dead after this, but... */
- reboot_type = BOOT_KBD;
- break;
-
- case BOOT_BIOS:
- machine_real_restart(MRR_BIOS);
-
- /* We're probably dead after this, but... */
- reboot_type = BOOT_TRIPLE;
- break;
-
- case BOOT_ACPI:
- acpi_reboot();
- reboot_type = BOOT_KBD;
- break;
-
case BOOT_EFI:
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi.reset_system(reboot_mode == REBOOT_WARM ?
EFI_RESET_WARM :
EFI_RESET_COLD,
EFI_SUCCESS, 0, NULL);
- reboot_type = BOOT_CF9_COND;
+ reboot_type = BOOT_BIOS;
+ break;
+
+ case BOOT_BIOS:
+ machine_real_restart(MRR_BIOS);
+
+ /* We're probably dead after this, but... */
+ reboot_type = BOOT_CF9_SAFE;
break;
- case BOOT_CF9:
+ case BOOT_CF9_FORCE:
port_cf9_safe = true;
/* Fall through */
- case BOOT_CF9_COND:
+ case BOOT_CF9_SAFE:
if (port_cf9_safe) {
- u8 reboot_code = reboot_mode == REBOOT_WARM ?
- 0x06 : 0x0E;
+ u8 reboot_code = reboot_mode == REBOOT_WARM ? 0x06 : 0x0E;
u8 cf9 = inb(0xcf9) & ~reboot_code;
outb(cf9|2, 0xcf9); /* Request hard reset */
udelay(50);
@@ -553,7 +549,15 @@ static void native_machine_emergency_restart(void)
outb(cf9|reboot_code, 0xcf9);
udelay(50);
}
- reboot_type = BOOT_BIOS;
+ reboot_type = BOOT_TRIPLE;
+ break;
+
+ case BOOT_TRIPLE:
+ load_idt(&no_idt);
+ __asm__ __volatile__("int3");
+
+ /* We're probably dead after this, but... */
+ reboot_type = BOOT_KBD;
break;
}
}
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 9e7db9e..48bf152 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -20,13 +20,13 @@ enum reboot_mode {
extern enum reboot_mode reboot_mode;
enum reboot_type {
- BOOT_TRIPLE = 't',
- BOOT_KBD = 'k',
- BOOT_BIOS = 'b',
- BOOT_ACPI = 'a',
- BOOT_EFI = 'e',
- BOOT_CF9 = 'p',
- BOOT_CF9_COND = 'q',
+ BOOT_TRIPLE = 't',
+ BOOT_KBD = 'k',
+ BOOT_BIOS = 'b',
+ BOOT_ACPI = 'a',
+ BOOT_EFI = 'e',
+ BOOT_CF9_FORCE = 'p',
+ BOOT_CF9_SAFE = 'q',
};
extern enum reboot_type reboot_type;
next prev parent reply other threads:[~2014-04-04 6:48 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 6:14 [BUG] x86: reboot doesn't reboot Steven Rostedt
[not found] ` <070BEF4AC20468458C22969097656CD91163106C@shsmsx102.ccr.corp.intel.com>
2014-04-03 6:30 ` FW: " Li, Aubrey
2014-04-03 12:09 ` Steven Rostedt
2014-04-03 13:41 ` Steven Rostedt
2014-04-03 13:45 ` Matthew Garrett
2014-04-03 14:10 ` H. Peter Anvin
2014-04-03 14:47 ` Steven Rostedt
2014-04-03 14:50 ` Matthew Garrett
2014-04-03 15:14 ` Steven Rostedt
2014-04-03 15:17 ` Steven Rostedt
2014-04-03 15:20 ` H. Peter Anvin
2014-04-03 15:21 ` H. Peter Anvin
2014-04-03 15:39 ` Steven Rostedt
2014-04-03 15:58 ` H. Peter Anvin
2014-04-03 16:13 ` Steven Rostedt
2014-04-03 23:23 ` Li, Aubrey
2014-04-03 23:40 ` Steven Rostedt
2014-04-03 23:52 ` Li, Aubrey
2014-04-04 0:12 ` H. Peter Anvin
2014-04-04 1:27 ` Li, Aubrey
2014-04-04 1:40 ` H. Peter Anvin
2014-04-04 6:13 ` Ingo Molnar
2014-04-04 12:34 ` H. Peter Anvin
2014-04-04 15:12 ` Matthew Garrett
2014-04-04 15:13 ` H. Peter Anvin
2014-04-04 15:36 ` Matthew Garrett
2014-04-04 15:39 ` H. Peter Anvin
2014-04-04 15:46 ` Matthew Garrett
2014-04-04 16:01 ` Steven Rostedt
2014-04-04 17:34 ` Ingo Molnar
2014-04-04 17:37 ` H. Peter Anvin
2014-04-04 17:44 ` Ingo Molnar
2014-04-04 18:00 ` Matthew Garrett
2014-04-04 15:38 ` Linus Torvalds
2014-04-04 15:45 ` Matthew Garrett
2014-04-04 15:54 ` Tobias Klausmann
2014-04-04 16:09 ` Linus Torvalds
2014-04-04 16:21 ` Matthew Garrett
2014-04-04 18:19 ` Linus Torvalds
2014-04-28 6:02 ` Yuhong Bao
2014-04-04 16:31 ` H. Peter Anvin
[not found] ` <cbb97256-9323-4d67-8523-061972e07ecc@email.android.com>
2014-04-04 17:01 ` H. Peter Anvin
2014-04-04 17:40 ` Ingo Molnar
2014-04-04 18:26 ` Linus Torvalds
2014-04-04 2:16 ` Steven Rostedt
2014-04-04 2:43 ` Li, Aubrey
2014-04-03 15:35 ` Steven Rostedt
2014-04-04 6:41 ` Ingo Molnar [this message]
2014-04-04 7:53 ` [PATCH] x86: Don't do the BIOS and PCI 0xCF9 reboot methods by default Ingo Molnar
2014-04-04 7:54 ` [tip:x86/reboot] [PATCH] x86: Try the BIOS reboot method before the PCI reboot method tip-bot for Ingo Molnar
2014-04-04 8:00 ` Ingo Molnar
2014-04-04 12:37 ` H. Peter Anvin
2014-04-04 13:30 ` Steven Rostedt
2014-04-04 13:38 ` Li, Aubrey
2014-04-04 15:09 ` Adam Williamson
2014-04-04 15:13 ` Matthew Garrett
2014-04-04 15:28 ` H. Peter Anvin
2014-04-06 17:40 ` One Thousand Gnomes
2014-04-06 18:40 ` H. Peter Anvin
2014-04-07 8:00 ` Li, Aubrey
2014-04-07 21:03 ` H. Peter Anvin
2014-04-07 22:04 ` Adam Williamson
2014-04-07 22:09 ` H. Peter Anvin
2014-04-07 23:12 ` Adam Williamson
2014-04-09 20:50 ` H. Peter Anvin
2014-04-04 17:48 ` Ingo Molnar
2014-04-04 19:12 ` Linus Torvalds
2014-04-07 15:42 ` Steven Rostedt
2014-04-14 11:22 ` [tip:x86/urgent] " tip-bot for Ingo Molnar
2014-04-14 11:27 ` Ingo Molnar
2014-04-14 16:04 ` Steven Rostedt
2014-04-16 7:40 ` [tip:x86/urgent] x86: Remove the PCI reboot method from the default chain tip-bot for Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140404064120.GB11877@gmail.com \
--to=mingo@kernel.org \
--cc=aubrey.li@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).