[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86: default to reboot via ACPI

* Pavel Machek <> wrote:

> On Mon 2008-08-25 13:11:27, Avi Kivity wrote:
> > Triple-fault and keyboard reset may assert INIT instead of RESET; however
> > INIT is blocked when Intel VT is enabled. This leads to a partially reset
> > machine when invoking emergency_restart via sysrq-b: the processor is still
> > working but other parts of the system are dead.
> >
> > Default to rebooting via ACPI, which correctly asserts RESET and reboots the
> > machine.
> >
> > This is safe since we will fall back to keyboard reset and triple fault if
> > acpi is not enabled or if the reset is not successful.
> >
> > Signed-off-by: Avi Kivity <>
> "ACPI" and "safe" in one sentence. /me bets this will break lot of
> machines.

maybe. OTOH, it's just about PIO accesses and those tend to be pretty
safe. I would not be surprised if Windows used the ACPI reboot sequence
too by default.

PIO access cannot really fail or fault (other than locking up in SMM
mode) - it can in practice be at most non-effective (the box wont
reboot) - in which case we'll still cycle through all the other current
reboot methods.

So i think we are on the safe side. Not for v2.6.27 obviously, but maybe
for v2.6.28, if all testing is a success. (which it is on a healthy
range of x86 hardware we test -tip on)

> What about only doing that when enabling VT?

hm, i'd much rather have consistent behavior, so that we have less
variables. If this breaks anywhere, we want to know about it ASAP and it
should be pretty debuggable. ('box hangs/crashes during reboot')

In fact this change might unbreak some systems - we have a ton of DMI
driven reboot quirks and i dont think they are anywhere close to
complete. It's also very easy to revert, if it were to cause any

What do you think?


 \ /
  Last update: 2008-08-26 12:39    [W:0.101 / U:16.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site