[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfbdc582-9fc0-4335-9974-d508c2da1c71@email.android.com>
Date: Sun, 02 Mar 2014 08:52:17 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
Matthew Garrett <mjg59@...f.ucam.org>
CC: "H. Peter Anvin" <hpa@...ux.intel.com>,
"alan@...ux.intel.com" <alan@...ux.intel.com>,
linux-kernel@...r.kernel.org, Len.Brown@...el.com,
Adam Williamson <awilliam@...hat.com>
Subject: Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop
We are unambiguously dead after BIOS. There is no retry possible...
On March 2, 2014 2:39:02 AM PST, "Li, Aubrey" <aubrey.li@...ux.intel.com> wrote:
>Patch refined as below, welcome any comments.
>
>Thanks,
>-Aubrey
>
>[PATCH] x86/reboot: Introduce all of the known reboot methods into the
>default list
>
>Reboot is the last service linux OS provides to the end user. We are
>supposed to make this function more robust than today. This patch adds
>all of the known reboot methods into the default attempt list. The
>machines requiring reboot=efi or reboot=p or reboot=bios get a chance
>to reboot automatically now.
>
>If there is a new reboot method emerged, we are supposed to add it to
>the default list as well, instead of adding the endless dmidecode
>entry.
>
>If one method required is in the default list in this patch but the
>machine reboot still hangs, that means some methods ahead of the
>required method cause the system hangs, then reboot the machine by
>passing reboot= arguments and submit the reboot dmidecode table quirk.
>
>We are supposed to remove the reboot dmidecode table from the kernel,
>but to be safe, we keep it. This patch prevents us from adding more.
>If you happened to have a machine listed in the reboot dmidecode
>table and this patch makes reboot work on your machine, please submit
>a patch to remove the quirk.
>
>Signed-off-by: Aubrey Li <aubrey.li@...el.com>
>---
> arch/x86/kernel/reboot.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
>diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>index c752cb4..807007f 100644
>--- a/arch/x86/kernel/reboot.c
>+++ b/arch/x86/kernel/reboot.c
>@@ -464,9 +464,12 @@ void __attribute__((weak))
>mach_reboot_fixups(void)
> * 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, 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
>(4) we'll
>+ * 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
> */
>@@ -502,7 +505,7 @@ static void native_machine_emergency_restart(void)
> attempt = 1;
> reboot_type = BOOT_ACPI;
> } else {
>- reboot_type = BOOT_TRIPLE;
>+ reboot_type = BOOT_EFI;
> }
> break;
>
>@@ -516,7 +519,7 @@ static void native_machine_emergency_restart(void)
> case BOOT_BIOS:
> machine_real_restart(MRR_BIOS);
>
>- reboot_type = BOOT_KBD;
>+ reboot_type = BOOT_TRIPLE;
> break;
>
> case BOOT_ACPI:
>@@ -530,7 +533,7 @@ static void native_machine_emergency_restart(void)
> EFI_RESET_WARM :
> EFI_RESET_COLD,
> EFI_SUCCESS, 0, NULL);
>- reboot_type = BOOT_KBD;
>+ reboot_type = BOOT_CF9;
> break;
>
> case BOOT_CF9:
>@@ -548,7 +551,7 @@ static void native_machine_emergency_restart(void)
> outb(cf9|reboot_code, 0xcf9);
> udelay(50);
> }
>- reboot_type = BOOT_KBD;
>+ reboot_type = BOOT_BIOS;
> break;
> }
> }
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists