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

[Li, Aubrey]

On 2014/3/2 1:22, Matthew Garrett wrote:
> 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?

Yes. we already have a case that the registers is valid without the bit 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.

Firmware actually writes CF9.


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

The design philosophy is as above. We didn't confirm, we try, we try to
match the user's final requirement. And it can be successful on 32bit
linux&EFI system. Do you have an explicit unpleasant result share with me?

> 
>> 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.
> 
I'm glad to hear this, :)

Thanks,
-Aubrey
--
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/