x86: reboot doesn't reboot

From: Steven Rostedt [mailto:[email protected]]
Sent: Thursday, April 03, 2014 2:14 PM
To: Linus Torvalds; LKML
Cc: Ingo Molnar; H. Peter Anvin; Thomas Gleixner; Li, Aubrey; Matthew Garrett
Subject: [BUG] x86: reboot doesn't reboot

I noticed that one of my test boxes no longer does a reboot with the latest kernel. It goes down and shows:

[   51.589896] reboot: Restarting system
[   51.593567] reboot: machine restart

And the system sounds like it turns off (the fans stop), but then I just sit there and wait, and wait and wait. The system never starts up again.

I did a bisect and it landed on: a4f1987e4c54 "x86, reboot: Add EFI and CF9 reboot methods into the default list" which looks like a very likely suspect. I removed that and fb3bd7b19b2b, as the second commit was just a fix up of the first, recompiled, installed and rebooted to that kernel. I tried to reboot again and sure enough after posting the "machine restart" I started getting those "Press any key to continue."
messages again. That's a good sign.

Linus mentioned to me to use "reboot=pci" on the kernel command line, but no dice. That doesn't seem to make a difference.

May I know if "reboot=t" make any difference on your system with the change?

May I know if "reboot=t" make any difference on your system with the change?

Quoted 1 line · Aubrey

May I know if "reboot=t" make any difference on your system with the change?

Is this the future fix? Or do you have patches for me to test. I'll be happy to test any patches you have on this box. If you need to know anything about this box, let me know and I'll run any command that would help you.

Quoted 1 line · Aubrey

May I know if "reboot=t" make any difference on your system with the change?

Is this the future fix? Or do you have patches for me to test. I'll be happy to test any patches you have on this box. If you need to know anything about this box, let me know and I'll run any command that would help you.

Could you tell which of these modes work on your box:

reboot=t

reboot=k

reboot=b (BIOS only)

reboot=a

reboot=e (EFI only)

reboot=p

Quoted 1 line

reboot=a

Passed

Quoted 3 lines · Steven Rostedt

Quoted 1 line

reboot=a

Passed

Huh. We should be trying the acpi method twice before we try PCI at all, unless something's gone very wrong.

On Thu, 03 Apr 2014 07:10:47 -0700

Passed

Quoted 1 line

reboot=a

Quoted 4 lines · On Thu, 3 Apr 2014 10:47:21 -0400 Steven Rostedt <[email protected]> wrote:

On Thu, 03 Apr 2014 07:10:47 -0700

Passed

Quoted 1 line

Quoted 1 line

reboot=a

After getting Matthew's email, I tried this again and it failed to boot. Let me rerun through the list again and I'll report back if things have changed.

Changing options, rebooting, changing options rebooting, gets a bit confusing. I may have rebooted the 'b' and thought it was the 'a'.

Also, can you send the dmidecode from your system? Is it a Dell?

Quoted 2 lines · H. Peter Anvin

Also, can you send the dmidecode from your system? Is it a Dell?

Quoted 1 line

(And I assume you're booting BIOS, not EFI.)

Hmm, I didn't see this email. Note, this box is an old development box that Intel sent me years ago.

Quoted 4 lines · Steven Rostedt

Hmm, I didn't see this email. Note, this box is an old development box that Intel sent me years ago.

Preproduction system?

Quoted 6 lines · On Thu, 03 Apr 2014 08:58:14 -0700 "H. Peter Anvin" <[email protected]> wrote:

Quoted 4 lines · Steven Rostedt

Hmm, I didn't see this email. Note, this box is an old development box that Intel sent me years ago.

Quoted 2 lines

Preproduction system?

Could be. Honestly, I don't remember. I use to get boxes from Intel and AMD randomly at my doorstep. Sometimes, a representative would actually tell me why I got it. I just took them and set them up in my test environment. Never really questioned why. I think these boxes are from 2006 or 2007.

Can you please send the dmi table out?

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc, did you not receive it?

Quoted 8 lines · Steven Rostedt

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc, did you not receive it?

Oh, I got it. This is a Preproduction machine.
When reboot failed via a method (=e or =p), there are two case.

Case 1: this method do nothing, pass the attempt chance to the next method Case 2: this method hangs the system

I want to know if CF9 is case 1 or case 2. Could you please try the following patch *without* any reboot parameters?

(1) If we didn't see any string, then EFI hangs your box.
(2) if we see the first string but not the second one, CF9 hangs your box
(3) if we see both, couldn't be, because BIOS works on your box.

Quoted 18 lines · Aubrey

Quoted 8 lines · Steven Rostedt

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc, did you not receive it?

Oh, I got it. This is a Preproduction machine.
When reboot failed via a method (=e or =p), there are two case.

Case 1: this method do nothing, pass the attempt chance to the next method Case 2: this method hangs the system

I want to know if CF9 is case 1 or case 2. Could you please try the following patch *without* any reboot parameters?

Quoted 4 lines

(1) If we didn't see any string, then EFI hangs your box.
(2) if we see the first string but not the second one, CF9 hangs your box
(3) if we see both, couldn't be, because BIOS works on your box.

Given that this machine doesn't have EFI, it seems kind of obvious, no?

-hpa

Quoted 8 lines · H. Peter Anvin

Quoted 7 lines · Aubrey

Quoted 6 lines · Steven Rostedt

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc,

did

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

you not receive it?

Oh, I got it. This is a Preproduction machine.
When reboot failed via a method (=e or =p), there are two case.

Case 1: this method do nothing, pass the attempt chance to the next

method

Quoted 3 lines

Quoted 3 lines

Case 2: this method hangs the system

I want to know if CF9 is case 1 or case 2. Could you please try the

following

Quoted 4 lines

Quoted 4 lines

patch *without* any reboot parameters?

(1) If we didn't see any string, then EFI hangs your box.
(2) if we see the first string but not the second one, CF9 hangs

your box

Quoted 4 lines

Quoted 2 lines

(3) if we see both, couldn't be, because BIOS works on your box.

Given that this machine doesn't have EFI, it seems kind of obvious,

no?

Quoted 2 lines

-hpa

Yes. it should be but I want to confirm.

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

So, if I understand correctly(please correct me if I was wrong), I don't
think the justification is enough to revert the patch. The patch includes EFI, CF9 and BIOS.

I'm open to make Steven's machine work:
(1) remove CF9
(2) add DMI table
(3) any other idea without a regression.

I prefer (2) or (3) if better because if we do (1) we will probably receive some other regression reports.

Thanks,
-Aubrey

Keep in mind we already tried CF9 in the default flow and it broke things. I'm willing to wait for reports about production machines, though, but I fully expect them.

Quoted 3 lines · H. Peter Anvin

Keep in mind we already tried CF9 in the default flow and it broke things. I'm willing to wait for reports about production machines, though, but I fully expect them.

Typically there's nothing particularly weird about preproduction Intel hardware when it comes to reboot methods, other than people more willing to test them with development kernels.

Is there any system were the triple fault method does not work?

Thanks,

Ingo

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

Quoted 4 lines · Aubrey

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

Production hardware should never require CF9.

Quoted 7 lines · Matthew Garrett

Quoted 4 lines · Aubrey

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

Quoted 2 lines

Production hardware should never require CF9.

There are a lot of things that shouldn't be.

Quoted 11 lines · H. Peter Anvin

Quoted 9 lines · Matthew Garrett

Quoted 4 lines · Aubrey

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

Production hardware should never require CF9.

Quoted 1 line

There are a lot of things that shouldn't be.

Windows doesn't hit CF9, and production hardware is always tested with Windows, so. Adding CF9 may make things work in some situations but it clearly breaks them in others - we'd be better off spending our time figuring out why systems that appear to need CF9 won't otherwise work.

There are several platforms where the default boot method invokes an SMM handler which blithly assumes that the hardware is in whatever state Windows leaves it in, and hangs otherwise. This seems to include nearly all Dell systems. So it isn't really quite that simple...

There are several platforms where the default boot method invokes an SMM handler which blithly assumes that the hardware is in whatever state Windows leaves it in, and hangs otherwise. This seems to include nearly all Dell systems. So it isn't really quite that simple...

Quoted 8 lines · H. Peter Anvin

Quoted 7 lines · Matthew Garrett

Quoted 4 lines · Aubrey

The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than one(could be thousand known) production machine works by CF9.

Quoted 4 lines

Quoted 2 lines

Production hardware should never require CF9.

There are a lot of things that shouldn't be.

Windows doesn't hit CF9, and production hardware is always tested with Windows, so. [...]

Quoted 6 lines · Matthew Garrett

Quoted 5 lines · H. Peter Anvin

Quoted 4 lines · Matthew Garrett

Quoted 2 lines · Aubrey

The current situation is,
- we have one(do we know more?) preproduction machine hangs by

CF9.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

- We have more than one(could be thousand known) production

machine

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

works by CF9.

Production hardware should never require CF9.

There are a lot of things that shouldn't be.

Windows doesn't hit CF9, and production hardware is always tested

with

Quoted 1 line

Windows, so. [...]

So why the hell does the reboot function comment claim that the Windows reboot sequence (which is the de facto hardware standard) uses 0xcf9:

/*
* Windows compatible x86 hardware expects the following on reboot:
*
* 1) If the FADT has the ACPI reboot register flag set, try it
* 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 *

??

Thanks,

Ingo

The comment header is bogus... it describes what we do, not what Windows does.

Before any other change is done beyond the revert of this latest broken commit.

Production hardware should never require CF9.

Quoted 2 lines · Matthew Garrett

Production hardware should never require CF9.

That's total BS.

The fact is, we may be doing something wrong, but ACPI fails on a *lot* of systems. A huge swath of Dell machines in particular for some reason (laptops, desktops, _and_ now there's tablet reports).

The keyboard controller is sadly unreliable too, although I really don't understand why. Even when a legacy keyboard controller exists (which isn't as universal as you'd think, even though the *hardware* is pretty much guaranteed to be there in the chipset, it can be disabled) there seem to be machines where the reset line isn't hooked up. Don't ask me why. Same goes for the triple fault failure case.

It would be interesting if somebody can figure out *exactly* what Windows does, because the fact that a lot of Dell machines need quirks almost certainly means that it's _us_ doing something wrong. Dell doesn't generally do lots of fancy odd things. I pretty much guarantee it's because we've done something odd that Windows doesn't do.

Quoted 7 lines · Linus Torvalds

Quoted 1 line · Matthew Garrett

Production hardware should never require CF9.

That's total BS.

The fact is, we may be doing something wrong, but ACPI fails on a *lot* of systems. A huge swath of Dell machines in particular for some reason (laptops, desktops, _and_ now there's tablet reports).

Which is almost certainly because the other reboot methods are trapping into SMI and hitting some hardware that we've left in a different state to Windows. CF9 may work around that, but the actual fix is to figure out why the firmware is wedging and fix it. Otherwise we're going to spend the rest of our lives maintaining a giant DMI list that's still going to be missing entries and users are going to be sad.

Quoted 6 lines

The keyboard controller is sadly unreliable too, although I really don't understand why. Even when a legacy keyboard controller exists (which isn't as universal as you'd think, even though the *hardware* is pretty much guaranteed to be there in the chipset, it can be disabled) there seem to be machines where the reset line isn't hooked up. Don't ask me why. Same goes for the triple fault failure case.

See: SMI. Or in the triple fault case, because there's some early init code that has the same issue. As far as I can tell Windows never triple faults, so again I think this is our fault at some level.

Quoted 5 lines

It would be interesting if somebody can figure out *exactly* what Windows does, because the fact that a lot of Dell machines need quirks almost certainly means that it's _us_ doing something wrong. Dell doesn't generally do lots of fancy odd things. I pretty much guarantee it's because we've done something odd that Windows doesn't do.

Windows hits the keyboard controller and then tries the ACPI vector. It then sleeps for a short period, then tries the keyboard controller again and the ACPI vector again. This means that systems which put cf9 in the ACPI vector tend to work because of the second write, which is obviously not what the spec envisaged but here we are. The only time it hits CF9 is when the ACPI tables tell it to.

Which is almost certainly because the other reboot methods are trapping into SMI and hitting some hardware that we've left in a different state to Windows.

Quoted 4 lines · Matthew Garrett

Which is almost certainly because the other reboot methods are trapping into SMI and hitting some hardware that we've left in a different state to Windows.

Why are you making up these completely invalid arguments? Because you are making them up.

Our default reboot type is REBOOT_ACPI. That's the one we try *first*. There are no "other reboot methods" playing games.

And given this *fact*, your denial that "PCI reboot should never be used" is counterfactual. It may be true in some theoretical "this is how the world should work" universe, but in the real world it is just BS.

Why are you so deep in denial about this?

Because Windows doesn't use CF9 but machines reboot anyway. That shouldn't be a controversial point of view.

I'll contact
the people I know in Dell and see if I can find anyone from the firmware division who'll actually talk to us.

Windows hits the keyboard controller and then tries the ACPI vector. It then sleeps for a short period, then tries the keyboard controller again and the ACPI vector again.

Windows does ACPI first, so no. And the Dells were broken even before we moved ACPI up the list.

Quoted 2 lines · Matthew Garrett

Windows does ACPI first, so no. And the Dells were broken even before we moved ACPI up the list.

That's not what you said a few posts ago.

Quoted 5 lines · Matthew Garrett

Windows hits the keyboard controller and then tries the ACPI vector. It then sleeps for a short period, then tries the keyboard controller again and the ACPI vector again.

So do you think we should move the KBC upward in our priority list? That would seem to be the obvious thing to do...

Quoted 8 lines · Steven Rostedt

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc, did you not receive it?

Oh, I got it. This is a Preproduction machine.
When reboot failed via a method (=e or =p), there are two case.

Case 1: this method do nothing, pass the attempt chance to the next method Case 2: this method hangs the system

I want to know if CF9 is case 1 or case 2. Could you please try the following patch *without* any reboot parameters?

(1) If we didn't see any string, then EFI hangs your box.
(2) if we see the first string but not the second one, CF9 hangs your box
(3) if we see both, couldn't be, because BIOS works on your box.

Quoted 15 lines · Aubrey

Quoted 8 lines · Steven Rostedt

Quoted 1 line · Aubrey

Can you please send the dmi table out?

I already did as a gz attachment to H. Peter. You were on the Cc, did you not receive it?

Oh, I got it. This is a Preproduction machine.
When reboot failed via a method (=e or =p), there are two case.

Case 1: this method do nothing, pass the attempt chance to the next method Case 2: this method hangs the system

Quoted 6 lines

I want to know if CF9 is case 1 or case 2. Could you please try the following patch *without* any reboot parameters?

(1) If we didn't see any string, then EFI hangs your box.
(2) if we see the first string but not the second one, CF9 hangs your box
(3) if we see both, couldn't be, because BIOS works on your box.

Here's the output:

[  114.445327] reboot: Restarting system
[  114.449002] reboot: machine restart
[  114.453495] reboot: reboot via CF9...

Quoted 3 lines · On Thu, 03 Apr 2014 07:10:47 -0700 "H. Peter Anvin" <[email protected]> wrote:

Could you tell which of these modes work on your box:

reboot=t

I already stated that 't' works.

Quoted 2 lines

reboot=k

Fails

Quoted 2 lines

reboot=b (BIOS only)

Passed

Quoted 2 lines

reboot=a

Passed

Quoted 2 lines

reboot=e (EFI only)

Fails

Quoted 2 lines

reboot=p

Fails

Quoted 1 line · On Thu, 03 Apr 2014 07:10:47 -0700 "H. Peter Anvin" <[email protected]> wrote:

Could you tell which of these modes work on your box:

Alternatively we could just use the following reboot order:

* 1) If the FADT has the ACPI reboot register flag set, try it
* 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, force a triple fault

I.e. eliminate the 'PCI' and 'BIOS' methods from our default sequence, as both are documented as being able to hang some boxes.

Commit-ID:  d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Gitweb:     http://git.kernel.org/tip/d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 4 Apr 2014 08:48:03 +0200

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

Quoted 2 lines · tip-bot for Ingo Molnar

Commit-ID: d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3 Gitweb:

http://git.kernel.org/tip/d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3

Quoted 6 lines

Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 4 Apr 2014 08:48:03 +0200

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Thanks,

Ingo

Quoted 7 lines · tip-bot for Ingo Molnar

Commit-ID:  d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Gitweb:     http://git.kernel.org/tip/d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 4 Apr 2014 08:48:03 +0200

Quoted 1 line

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Quoted 3 lines

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Thanks,

Ingo

<cc to adam>

Quoted 4 lines · Ingo Molnar

Quoted 3 lines

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

Quoted 8 lines

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Thanks,

Ingo

The change is originated from the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=70931

The system will hang after BIOS or TRIPLE if it doesn't work, that's why I added CF9 before BIOS and TRIPLE.

Adam may want to try this change to see if reboot works on his DELL Venue 8 Pro.

I don't think there is enough justification to revert the patch. We introduce EFI into the default list, we didn't see any reason to remove it out so far.

I don't think there is enough justification to revert the patch. We introduce EFI into the default list, we didn't see any reason to remove it out so far.

Quoted 3 lines · Aubrey

I don't think there is enough justification to revert the patch. We introduce EFI into the default list, we didn't see any reason to remove it out so far.

We should be using the EFI method, yes. But it seems that CF9 isn't safe, so we should drop that.

Quoted 3 lines · Aubrey

I don't think there is enough justification to revert the patch. We introduce EFI into the default list, we didn't see any reason to remove it out so far.

We should be using the EFI method, yes. But it seems that CF9 isn't safe, so we should drop that.

Quoted 9 lines · On Fri, 4 Apr 2014 16:13:59 +0100 Matthew Garrett <[email protected]> wrote:

Quoted 3 lines · Aubrey

I don't think there is enough justification to revert the patch. We introduce EFI into the default list, we didn't see any reason to remove it out so far.

We should be using the EFI method, yes. But it seems that CF9 isn't safe, so we should drop that.

Windows does not use CF9 and there are known, documented cases where CF9 will not work reliably. That includes reliable reboot on some Baytrail systems. (Erratum VLT60 and VLT62).

So we really shouldn't be doing 0xCF9 except as a last resort if we are still alive and have been through the official reboot methods.

No question. The question at hand is if we should do it after all other non-terminal (BIOS, triple) methods have been tried.

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

Quoted 11 lines · Aubrey

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?

Quoted 10 lines

so, it sounds like...

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

Quoted 4 lines

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?

Yep. And it has now been shown again that CF9 just isn't safe. We do TRIPLE as the ultimate fallback now.

basically, we know that we probably can't come up with a standard fallback chain that will work for *every* system, and the goal instead is to come up with the approach that requires the *fewest* quirks.

<cc to adam>

Quoted 4 lines · Ingo Molnar

Quoted 3 lines

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

Quoted 8 lines

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Thanks,

Ingo

The change is originated from the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=70931

The system will hang after BIOS or TRIPLE if it doesn't work, that's why I added CF9 before BIOS and TRIPLE.

Adam may want to try this change to see if reboot works on his DELL Venue 8 Pro.

I don't think there is enough justification to revert the patch. [...]

'Breaks a box' is more than enough justification to revert a patch...

Quoted 7 lines · tip-bot for Ingo Molnar

Commit-ID:  d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Gitweb:     http://git.kernel.org/tip/d122ab8d224a59aa0c3e4ba3540c6ab99556c3e3
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 4 Apr 2014 08:48:03 +0200

Quoted 1 line

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

So, JFYI, I have put this into x86/reboot to get it tested, but it's not queued up for upstream yet until there's concensus.

(Steve testing it wouldn't hurt either.)

Commit-ID:  f042310bf8a846bcf21012ffee78d9eb562a7fa4
Gitweb:     http://git.kernel.org/tip/f042310bf8a846bcf21012ffee78d9eb562a7fa4
Author:     Ingo Molnar <[email protected]>
AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Mon, 14 Apr 2014 13:13:30 +0200

[PATCH] x86: Try the BIOS reboot method before the PCI reboot method

Steve reported a reboot hang and bisected it back to this commit:

a4f1987e4c54 x86, reboot: Add EFI and CF9 reboot methods into the default list

He heroically tested all reboot methods and found the following:

  reboot=t       # triple fault                  ok
  reboot=k       # keyboard ctrl                 FAIL
  reboot=b       # BIOS                          ok
  reboot=a       # ACPI                          FAIL
  reboot=e       # EFI                           FAIL   [system has no EFI]
  reboot=p       # PCI 0xcf9                     FAIL

And I think it's pretty obvious that we should only try 0xcf9 as a last resort - if at all.

The other observation is that (on this box) we should never try the PCI reboot method, but close with either the 'triple fault' or the 'BIOS' (terminal!) reboot methods.

Thirdly, CF9_COND is a total misnomer - it should be something like CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...

So this patch fixes the worst problems:

- it orders the actual reboot logic to follow the reboot ordering pattern - it was in a pretty random order before for no good reason.

- it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and BOOT_CF9_SAFE flags to make the code more obvious.

- it tries the BIOS reboot method before the PCI reboot method. (Since 'BIOS' is a terminal reboot method resulting in a hang if it does not work, this is essentially equivalent to removing the PCI reboot method from the default reboot chain.)

- just for the miraculous possibility of terminal (resulting in hang) reboot methods of triple fault or BIOS returning without having done their job, there's an ordering between them as well.

Reported-and-bisected-and-tested-by Steven Rostedt <[email protected]>

Cc Li Aubrey <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Matthew Garrett <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

+ * To the best of our knowledge Windows compatible x86 hardware expects
+ * the following on reboot:
*
* 1) If the FADT has the ACPI reboot register flag set, try it
* 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 no EFI runtime service, call the BIOS to do a reboot

*
+ * We default to following the same pattern. We also have
+ * two other reboot methods: 'triple fault' and 'PCI', which
+ * can be triggered via the reboot= kernel boot option or
+ * via quirks.
+ *
+ * This means that this function can never return, it can misbehave
+ * by not rebooting properly and hanging.

So I rebased the patch Steve tested as-is and only fixed the patch description and some comments in the code, preserving Steve's testing status, and propagated it into x86/urgent.