Date:	Mon, 07 Apr 2014 15:04:52 -0700
From:	Adam Williamson <awilliam@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Li, Aubrey" <aubrey.li@...ux.intel.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, rostedt@...dmis.org,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/reboot] [PATCH] x86: Try the BIOS reboot method before
 the PCI reboot method

On Mon, 2014-04-07 at 14:03 -0700, H. Peter Anvin wrote:
> On 04/07/2014 01:00 AM, Li, Aubrey wrote:
> > 
> > EFI is no question. So, Is everybody okay with the following sequence?
> > (1) ACPI
> > (2) KEYBOARD
> > (3) ACPI
> > (4) KEYBOARD
> > (ADD_1) EFI
> > (5) TRIPLE
> > (ADD_2) CF9
> > (ADD_3) BIOS
> > 
> 
> No.  Because after "triple" there is NOTHING.  Putting anything after it
> is a joke.
> 
> How many times do I have to explain this to how many people?  If
> "triple" or "BIOS" doesn't work, there is no trying again... the machine
> is dead.

So if I'm following correctly, we should be able to sort the methods
into three buckets:

1) known to (almost) always be 'safe'
2) may cause system freeze if they fail
3) definitely cause system freeze if they fail

We put the methods from bucket 1) first, in whichever order makes the
most sense. Then we put any methods from bucket 2), in an order derived
from some kind of likelihood of success / likelihood of hang on fail
calculation. And at the end we can put precisely *one* method from
bucket 3, which should obviously be the one most likely to succeed on
the most systems which haven't already worked with one of the other
methods. We can't have more than one bucket 3) method, it just doesn't
make sense.

It sounds like at least TRIPLE and BIOS are 'bucket 3' methods, so it
seems like we have to pick which of the two we think is most useful, put
it last, and not have the other one. Of the new methods it sounds like
EFI is 'bucket 1', BIOS is 'bucket 3', and CF9 is 'bucket 2'.

so, it sounds like...

1) ACPI
2) KEYBOARD
3) ACPI
4) KEYBOARD
5) EFI
possibly 6) CF9
7) TRIPLE *or* BIOS

is what you would say makes sense, right? And really all there is to
decide is whether to include CF9, and whether to put TRIPLE or BIOS at
the end?

Again if I'm following correctly, this ought to be fine for Baytrail
devices - the ones we were trying to fix in the first place - because
they'll succeed with EFI. The justification for adding CF9 in the first
place wasn't very strong - it was just thrown in as a 'bonus extra',
more or less:

"These platforms [Baytrail] don't support ACPI reboot, we expect to call
EFI runtime service to handle this case, and CF9 is an alternate after
EFI."

so it doesn't seem unreasonable to remove it. The machine we're
currently trying to 'fix' needed TRIPLE in order to reboot correctly, it
seems. So again if I'm following correctly, that would suggest we should
have:

1) ACPI
2) KEYBOARD
3) ACPI
4) KEYBOARD
5) EFI
6) TRIPLE

I can patch that into reboot.c and confirm baytrails still work, if
that's desired.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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