Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 0:52, H. Peter Anvin wrote:
> We are unambiguously dead after BIOS.  There is no retry possible...

No really. Given that we add all of the known methods into the default
list, and BIOS is the last method, if your system hits BIOS, that means
ACPI/KBD/EFI/PCI can't make your system reboot, so BIOS should make it
work.

If you have a system can't be rebooted by all of the known methods, we
have to figure out how to make reboot work and add the new methods.

Does this make sense?

Thanks,
-Aubrey


> 
> On March 2, 2014 2:39:02 AM PST, "Li, Aubrey" <aubrey.li@xxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>> ---
>> 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;
>> 		}
>> 	}
> 

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