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

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:

> Peter - Can you please clarify writing to cf9 caused some system hang.
> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
> then if no CF9, the system hangs there in  infinite for() loop. If CF9
> is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
> system hang, right? If the answer is no, can you please point me which
> system hangs by CF9. I'd like to investigate what the ACPI reboot
> vectors look like on these systems.

I think I'm fine with cf9 being in there as long as it comes after the 
ACPI calls and as long as we're using either conf1 or conf2 access.

> I know, cf9 is not an architectural way, twice ACPI call has no spec

> (1) ACPI
> (2) keyboard
> (3) ACPI
> (4) keyboard
> (5) FADT sleep register as long as it's valid(!=0)
> (6) FADT sleep registers once again(since we try ACPI twice)

ACPI is the FADT sleep register - there's no separate ACPI reboot call. 
Do you mean try this again even if the valid bit isn't set?

> (7) EFI (interesting, I found it's eventually CF9 on some my
> investigated systems. No need to wait Matt's patch, it gives a chance to
> reboot 32bit kernel on 32bit EFI today)

No. The EFI reboot call jumps into the firmware and executes code. We 
don't want to do that until we ensure that there's an appropriate 
mapping in place because the consequences could be unpleasent. There is 
code to do this, let's just wait until it's merged.

> Also, we should add if a new method is emerged, instead of keeping
> adding those freak/endless reboot dmidecode table. Those quirks were not
> supposed to be in the kernel. We should remove them.

Hey I am absolutely fine with removing DMI lists under almost all 
circumstances.

-- 
Matthew Garrett | mjg59@srcf.ucam.org