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 <[email protected]>
---
arch/x86/kernel/reboot.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 724adfc..f4c93f1 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -29,7 +29,11 @@ EXPORT_SYMBOL(pm_power_off);
static const struct desc_ptr no_idt = {};
static int reboot_mode;
-enum reboot_type reboot_type = BOOT_KBD;
+/*
+ * Keyboard reset and triple fault may result in INIT, not RESET, which
+ * doesn't work when we're in vmx root mode. Try ACPI first.
+ */
+enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
#if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
--
1.6.0
* Avi Kivity <[email protected]> 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 <[email protected]>
applied to tip/x86/reboot - thanks Avi!
Ingo
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 <[email protected]>
"ACPI" and "safe" in one sentence. /me bets this will break lot of
machines.
What about only doing that when enabling VT?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> "ACPI" and "safe" in one sentence. /me bets this will break lot of
> machines.
>
>
We're in 2008 according to date(1).
> What about only doing that when enabling VT?
> Pavel
>
>
It seems excessive. Most machines will hardly run without acpi.
--
error compiling committee.c: too many arguments to function
* Pavel Machek <[email protected]> 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 <[email protected]>
>
> "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
trouble.
What do you think?
Ingo
> It seems excessive. Most machines will hardly run without acpi.
*Recent* machines.
2008/8/26 Avi Kivity <[email protected]>:
> It seems excessive. Most machines will hardly run without acpi.
Well, I'm fairly sure that most of the systems running linux (or some
variant like uclinux), do not support acpi.
Linux is used a lot in embedded systems (like routers and NAS-es and
probably set-top boxes). I guess the # of embedded systems with some
linux flavour on it is substantially bigger than the desktop systems.
Most of these are ARM or MIPS based and do not support ACPI.
Frans.
* Frans Meulenbroeks <[email protected]> wrote:
> 2008/8/26 Avi Kivity <[email protected]>:
>
> > It seems excessive. Most machines will hardly run without acpi.
>
> Well, I'm fairly sure that most of the systems running linux (or some
> variant like uclinux), do not support acpi.
>
> Linux is used a lot in embedded systems (like routers and NAS-es and
> probably set-top boxes). I guess the # of embedded systems with some
> linux flavour on it is substantially bigger than the desktop systems.
> Most of these are ARM or MIPS based and do not support ACPI.
... which is not an issue in this particular discussion, which was about
x86 with ACPI support enabled and available, whether in that case (and
only in that case) we should first try the ACPI reboot ports (that the
ACPI descriptors advertise) before also trying the other methods (kdb,
bios, triple fault, etc.) to reboot the box.
Ingo
> Linux is used a lot in embedded systems (like routers and NAS-es and
> probably set-top boxes). I guess the # of embedded systems with some
> linux flavour on it is substantially bigger than the desktop systems.
> Most of these are ARM or MIPS based and do not support ACPI.
They also don't support VT and are not x86 boxes so the code area
involved doesn't even get compiled on them.
Pavel Machek <[email protected]> writes:
>
> "ACPI" and "safe" in one sentence.
ACPI is safe in that a lot of systems won't even boot anymore without ACPI.
> /me bets this will break lot of machines.
The ACPI reboot is just a write to a IO port with a fallback, so it
should be fairly safe even if the field should be wrong.
-Andi
Alan Cox wrote:
>> It seems excessive. Most machines will hardly run without acpi.
>>
>
> *Recent* machines.
>
Most machines are recent machines.
If a machine doesn't have acpi, this change is safe.
If a machine has acpi, but doesn't have the reset register set in the
FADT, this change is safe.
If a machine has acpi, and the reset register is set incorrectly, this
change is safe.
If a machine has acpi, and the reset register is wired to the launch
controller, then perhaps this change is unsafe. Don't issue sysrq-b on
such machines.
--
error compiling committee.c: too many arguments to function
Avi Kivity <[email protected]> writes:
>
> If a machine has acpi, and the reset register is wired to the launch
> controller, then perhaps this change is unsafe. Don't issue sysrq-b
> on such machines.
Even if it's wired to the launch controller the launch controller
would need to be quite quick to do something before the following
triple fault/keyboard reset->PCI reset stops it again.
-Andi
On Tue, 26 Aug 2008, Avi Kivity wrote:
> Most machines are recent machines.
This is a bold statement I would say. Any numbers to back it up?
> If a machine doesn't have acpi, this change is safe.
>
> If a machine has acpi, but doesn't have the reset register set in the
> FADT, this change is safe.
>
> If a machine has acpi, and the reset register is set incorrectly, this
> change is safe.
>
> If a machine has acpi, and the reset register is wired to the launch
> controller, then perhaps this change is unsafe. Don't issue sysrq-b on
> such machines.
If a machine has ACPI and it is broken randomly, then the results can be
arbitrary. Hopefully not destructively. If even such a simple thing as
wiring the reset line so that it functions correctly can be got wrong,
more so can be more complex matters.
Failing a better alternative, I suppose the change has to go in though.
Maciej
Maciej W. Rozycki wrote:
> On Tue, 26 Aug 2008, Avi Kivity wrote:
>
>
>> Most machines are recent machines.
>>
>
> This is a bold statement I would say. Any numbers to back it up?
>
>
Only common sense. Non-recent machines are barely usable these days.
Sure they work well as a firewall or server-in-a-closet, but if you run
a desktop or a server that actually does useful work, you're running a
relatively recent machine.
>> If a machine has acpi, and the reset register is wired to the launch
>> controller, then perhaps this change is unsafe. Don't issue sysrq-b on
>> such machines.
>>
>
> If a machine has ACPI and it is broken randomly, then the results can be
> arbitrary. Hopefully not destructively. If even such a simple thing as
> wiring the reset line so that it functions correctly can be got wrong,
> more so can be more complex matters.
>
If we find that the reset was wired to the launch controller after all,
we can back out the change (after we re-evolve technology and Linux;
after all we are doomed to keep reinventing it, aren't we?).
> Failing a better alternative, I suppose the change has to go in though.
>
Let's see what breaks, if any. I understand the disgust people feel
when ACPI is mentioned, but we can't ignore reality.
--
error compiling committee.c: too many arguments to function
On Tue 2008-08-26 16:33:37, Avi Kivity wrote:
> Maciej W. Rozycki wrote:
> >On Tue, 26 Aug 2008, Avi Kivity wrote:
> >
> >
> >>Most machines are recent machines.
> >>
> >
> > This is a bold statement I would say. Any numbers to
> > back it up?
> >
> >
>
> Only common sense. Non-recent machines are barely
> usable these days. Sure they work well as a firewall or
> server-in-a-closet, but if you run a desktop or a server
> that actually does useful work, you're running a
> relatively recent machine.
reboot needs to work on servers-in-a-closet, too.
Anyway, I guess the change should go in. Lets see what breaks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 26 Aug 2008, Avi Kivity wrote:
> Only common sense. Non-recent machines are barely usable these days.
> Sure they work well as a firewall or server-in-a-closet, but if you run
> a desktop or a server that actually does useful work, you're running a
> relatively recent machine.
Hmm, it may have been true not so long ago, though not necessarily so
because of less affordability. These days hardware is more and more
affordable, but for several years the performance of hardware increased at
a rate substantially higher than the demand for resources from software
did. Therefore unless you are into HPC or use some inferior pieces of
software beyond the scope of this mailing list, older pieces of hardware
are often more than adequate to get your work done, so for some there is
little incentive to upgrade. Especially as upgrades are not necessarily
convenient for example because suddenly you lose something you have got
used to with your older equipment which the new one does not have.
My old x86 laptop I scrapped earlier this year was eight years old and
still up to its task and working fine except its enclosure fell apart.
The new one has the graphic driver barely working (no resolution switching
for example, the text mode gets garbled upon switching occasionally and
sometimes the console goes off entirely), plus a number of less annoying
issues I was not really eager to have. I would have kept the old gear if
I had had a way to replace the enclosure.
My best MIPS64 box is five years old and still decent enough to get its
work done. I do not seek a replacement.
Overall I am afraid common sense can sometimes be misleading, especially
as it varies from person to person.
> If we find that the reset was wired to the launch controller after all,
> we can back out the change (after we re-evolve technology and Linux;
> after all we are doomed to keep reinventing it, aren't we?).
The problem is it will work for us and then hit an unsuspecting innocent
user out there, someone not competent enough in the area of computer
hardware to have an idea what may be going wrong. And most certainly it
won't be the launch controller (whatever the thing is -- some military
equipment?), but some other random piece of hardware it will have been
wired to by someone on a whim.
> Let's see what breaks, if any. I understand the disgust people feel
> when ACPI is mentioned, but we can't ignore reality.
The disgust is expressed for future generations to get a lesson or
perish.
Maciej
On Tue, 26 Aug 2008, Pavel Machek wrote:
> reboot needs to work on servers-in-a-closet, too.
More importantly even, I would say, as failing to do so will cost some a
drive to a remote location in the middle of the night on a weekend or some
holiday.
Maciej
"Maciej W. Rozycki" <[email protected]> writes:
> On Tue, 26 Aug 2008, Avi Kivity wrote:
>
>> Most machines are recent machines.
>
> This is a bold statement I would say. Any numbers to back it up?
You can do the math. Reasonable assumptions are ~10% growth rate
in year-by-year units shipment (that's conservative, usually it is higher)
and that most systems are only used for 4-5 years (on commercial servers
it's typically 4 years, on privately used systems perhaps a bit more,
laptops certainly less because they tend to break earlier). That
is the average, of course there are systems which are used much
longer (or much shorter), but I would expect them to be the minority.
Also laptops are growing more and more compared to desktops (iirc the
cross over of more laptops than desktops shipping happened recently)
and if the assumption that they break earlier is true (it is
definitely in my experience) so it's likely that the average system
live time shrinks in the future.
With that it's reasonably easy to show that most systems are recent,
if you define recent as 1-3 years. The "ACPI is the standard validated
mode of operation" window is more like 7-8 years by now. With that
I would expect the systems with very poor ACPI implementation to
be a small minority by now.
-Andi
> Only common sense. Non-recent machines are barely usable these days.
> Sure they work well as a firewall or server-in-a-closet, but if you run
> a desktop or a server that actually does useful work, you're running a
> relatively recent machine.
Or a properly written desktop, or a thin client for desktop or ...
The really old boxes are actually not the problem, we don't try and use
ACPI on them so we won't try ACPI reboot. For those later ones it is
probably worth trying anyway - we might end up with a different blacklist
to before but there are multiple servers that really don't like old style
reboot nowdays.
Alan
On Tue 2008-08-26 18:16:42, Andi Kleen wrote:
> "Maciej W. Rozycki" <[email protected]> writes:
>
> > On Tue, 26 Aug 2008, Avi Kivity wrote:
> >
> >> Most machines are recent machines.
> >
> > This is a bold statement I would say. Any numbers to back it up?
>
> You can do the math. Reasonable assumptions are ~10% growth rate
> in year-by-year units shipment (that's conservative, usually it is higher)
> and that most systems are only used for 4-5 years (on commercial servers
> it's typically 4 years, on privately used systems perhaps a bit more,
> laptops certainly less because they tend to break earlier). That
> is the average, of course there are systems which are used much
> longer (or much shorter), but I would expect them to be the minority.
>
> Also laptops are growing more and more compared to desktops (iirc the
> cross over of more laptops than desktops shipping happened recently)
> and if the assumption that they break earlier is true (it is
> definitely in my experience) so it's likely that the average system
> live time shrinks in the future.
I'd not count of this. When you relegate laptop to "quiet home server"
role, the mechanical stresses suddenly stop, and I'd expect it to
survive for long long years.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> I'd not count of this. When you relegate laptop to "quiet home server"
> role, the mechanical stresses suddenly stop, and I'd expect it to
> survive for long long years.
>
For every user who uses an old laptop as a home server, or has a "best
MIPS64 box", there are maybe five million users with a 0-3 year old x86
computer (they don't know that it's really a "box").
Let's optimize for the common case, please.
--
error compiling committee.c: too many arguments to function
On Wed 2008-08-27 13:51:41, Avi Kivity wrote:
> Pavel Machek wrote:
> >I'd not count of this. When you relegate laptop to
> >"quiet home server"
> >role, the mechanical stresses suddenly stop, and I'd
> >expect it to
> >survive for long long years.
> >
>
> For every user who uses an old laptop as a home server,
> or has a "best MIPS64 box", there are maybe five million
> users with a 0-3 year old x86 computer (they don't know
> that it's really a "box").
Five million... um yes, probably, and those five million users run
Windows Vista...
So lets not introduce regressions, please.
(Anyway, the patch is probably good, but 'old machines do not matter'
is not.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html