User: Password:
|
|
Subscribe / Log in / New account

Garrett: Rebooting

Matthew Garrett appears to be having some "fun" looking into how to reboot x86 hardware. He lists five different mechanisms to reboot 64-bit x86 hardware including: "kbd - reboot via the keyboard controller. The original IBM PC had the CPU reset line tied to the keyboard controller. Writing the appropriate magic value pulses the line and the machine resets. This is all very straightforward, except for the fact that modern machines don't have keyboard controllers (they're actually part of the embedded controller) and even more modern machines don't even pretend to have a keyboard controller. Now, embedded controllers run software. And, as we all know, software is dreadful. But, worse, the software on the embedded controller has been written by BIOS authors. So clearly any pretence that this ever works is some kind of elaborate fiction. Some machines are very picky about hardware being in the exact state that Windows would program. Some machines work 9 times out of 10 and then lock up due to some odd timing issue. And others simply don't work at all. Hurrah!"
(Log in to post comments)

Garrett: Rebooting

Posted May 31, 2011 23:41 UTC (Tue) by welinder (guest, #4699) [Link]

In get the feeling that Matthew, in a previous life, must have offended
the Powers That Be severely. Why else does he have to deal with that?

Garrett: Rebooting

Posted Jun 1, 2011 0:58 UTC (Wed) by PaulWay (subscriber, #45600) [Link]

"Some of them are 32-bit only and so I'm just going to ignore them because honestly just what are you doing with your life. Also, they're horrible."

Honestly, this must go into the quote list for this week's news wrap-up. Very, very matthew garrett.

Have fun,

Paul

Garrett: Rebooting

Posted Jun 1, 2011 5:20 UTC (Wed) by StevenEllis (guest, #74851) [Link]

The things a guy will look at to avoid debugging EFI.

As ever insightful and downright amusing in all the wrong ways.

Sixth mechanism

Posted Jun 1, 2011 5:49 UTC (Wed) by pr1268 (subscriber, #24648) [Link]

He forgot one rebooting technique: Pull the power cord, re-insert, and press the power button. Of course, if this is a portable computer, you'll need to remove the battery first. :-)

Granted, pressing the reset button would qualify as a seventh method, but my experience is that most consumer-grade desktops and laptops don't bother including a reset button anymore (although my home-built case has one and the Intel MoBo I use supports it). Going off on a tangent, I wonder if the reset button invokes one of the five mechanisms MJG mentions...?

Sixth mechanism

Posted Jun 1, 2011 7:37 UTC (Wed) by PaulWay (subscriber, #45600) [Link]

Since I think he's mostly concerned with ways that the operating system itself can trigger a reset, it's somewhat academic to consider it pulling its own power cord.

And I believe the reset switch toggles a reset pin on the chip, or at least it did long ago. It's a worthy question.

Have fun,

Paul

Sixth mechanism

Posted Jun 1, 2011 9:55 UTC (Wed) by dgm (subscriber, #49227) [Link]

I can imagine ways for a computer to pull its own plug, but... plug it again afterwards? And then push the power button?? *That* is challenging.

Sixth mechanism

Posted Jun 1, 2011 11:53 UTC (Wed) by maney (subscriber, #12630) [Link]

Not if it's connected to a UPS that's got the minimal smarts to shutdown even in the presence of AC, pause, and then turn back on. I could demonstrate that, but then I wouldn't be able to finish thi

Sixth mechanism

Posted Jun 1, 2011 17:09 UTC (Wed) by nye (guest, #51576) [Link]

For some reason, now I'm thinking of this: http://www.youtube.com/watch?v=UmQ5LsNMXZ4

Sixth mechanism

Posted Jun 1, 2011 19:10 UTC (Wed) by pr1268 (subscriber, #24648) [Link]

Nice! Of course, I'm reminded of the famous line "I'm sorry, Dave. I'm afraid I can't do that."

Sixth mechanism

Posted Jun 2, 2011 22:38 UTC (Thu) by chad.netzer (subscriber, #4257) [Link]

Some gizmos can be a real lifesaver: http://www.kvm-switches-online.com/iboot.html

Sixth mechanism

Posted Jun 1, 2011 9:34 UTC (Wed) by error27 (subscriber, #8346) [Link]

On my laptop (Samsung RV511) you have to hold the power key down for 10 seconds to trigger a power off. It works great unless the kernel is panicked, in which case you need to unplug and remove the battery.

Sixth mechanism

Posted Jun 1, 2011 10:34 UTC (Wed) by bk (guest, #25617) [Link]

My understanding is that the "long press power button for hard reset" is (or was) part of the original ITX power spec, and so *should* have nothing to do with software.

However I guess with mobile machines the behavior will vary, since on some level they are emulating ITX within firmware. A kernel lockup still shouldn't matter.

Sixth mechanism

Posted Jun 1, 2011 13:15 UTC (Wed) by marcH (subscriber, #57642) [Link]

> On my laptop (Samsung RV511) you have to hold the power key down for 10 seconds to trigger a power off.

I have seen that working on every decently recent PC (not just laptops).

Sixth mechanism

Posted Jun 1, 2011 20:04 UTC (Wed) by hitmark (guest, #34609) [Link]

Yep, it is part of the change from AT (power button wired directly to the PSU) to ATX (power button as a "short" on the motherboard that then signals the PSU).

Sixth mechanism

Posted Jun 1, 2011 20:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

The behaviour then became embodied in the ACPI spec (holding the power button for more than 4 seconds is supposed to transition into G2), but on modern laptops this is usually managed by the embedded controller rather than the switch being inlined with the PSU or battery in any way. And, inevitably, various vendors get this wrong. I've got a Vaio that won't turn off if you oops, because every time the EC blinks the LEDs it forgets the power button state and so doesn't think it's been pressed for long enough.

Garrett: Rebooting

Posted Jun 3, 2011 8:17 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

There's a firmware patch for the PC I'm writing this on (a 64-bit mainstream PC that's less than 5 years old) which supposedly fixes the following bug which I have verified exists:

* Reset does not work. After the rest button [a hardware button] is pressed a corrupt screen is displayed and the computer does not work until physically powered off.

I have never applied this fix, if that's a bug that survived into shipping hardware, why would I conceivably want newer versions that presumably went through the same worthless QA process and may have worse bugs?

Garrett: Rebooting

Posted Jun 3, 2011 16:44 UTC (Fri) by johnny (guest, #10110) [Link]

I don't really get the conclusion of the article:

"And, shockingly, it turns out that on most systems the ACPI reboot vector points at 0xcf9 in system IO space. Even though most implementations nominally require two different values be written, it seems that this isn't a strict requirement and the ACPI method works."

I don't understand what Matthew means here. How does this relate to the "gaps" between writes, and how does it make reboots work better?

I've had a couple of cold ones so my brain might not be functioning at peak performance right now. Still, I'd appreciate an elaboration. :-)

Garrett: Rebooting

Posted Jun 3, 2011 17:00 UTC (Fri) by Trelane (subscriber, #56877) [Link]

> "And, shockingly, it turns out that on most systems the ACPI reboot vector points at 0xcf9 in system IO space. Even though most implementations nominally require two different values be written, it seems that this isn't a strict requirement and the ACPI method works."
> I don't understand what Matthew means here. How does this relate to the "gaps" between writes, and how does it make reboots work better?

It doesn't; it points out that the ACPI method is often just a half-assed way of doing the PCI method (because although technically two values are required, only one is apparently *necessary*.

The gap points to the fact that so much of the hardware is oriented toward the particular way that Windows does things that Linux has to painfully reverse-engineer every minute detail or else hardware starts breaking and Linux gets blamed because "It Works Under Windows Just Fine." Apparently, on some systems, not hitting ACPI (really just half-assed PCI), hitting the keyboard method, and then hitting ACPI again is what is *required* to properly reboot the system. Because That's How Windows Does It and We Don't Support Anything Else.

The PCI method, from the article:
> pci - not actually pci. Traditional PCI config space access is achieved by writing a 32 bit value to io port 0xcf8 to identify the bus, device, function and config register. Port 0xcfc then contains the register in question. But if you write the appropriate pair of magic values to 0xcf9, the machine will reboot. Spectacular! And not standardised in any way (certainly not part of the PCI spec), so different chipsets may have different requirements. Booo.

Synopsis: stop buying Windows hardware (laptops, desktops, servers, etc.) if you want Linux to work on your computer. :) [this is the long-term solution: make Linux impossible for (at least a significant subset of the) hardware vendors to ignore so that hardware will work with Linux without the hassle of figuring out The Way Windows Does It.]

Garrett: Rebooting

Posted Jun 3, 2011 17:01 UTC (Fri) by Trelane (subscriber, #56877) [Link]

s/ not hitting ACPI / hitting ACPI /

Garrett: Rebooting

Posted Jun 6, 2011 19:26 UTC (Mon) by zlynx (subscriber, #2285) [Link]

Good luck with that...

You might convince server builders, but when Windows has 90% of the market share for desktops and laptops you'll never convince Samsung, Gigabyte or ASUS (for example) to bother testing with Linux. They won't even notice the drop in sales if Linux users stop buying from them.

Garrett: Rebooting

Posted Jun 6, 2011 19:59 UTC (Mon) by Trelane (subscriber, #56877) [Link]

The part you're apparently referring to is
> Synopsis: stop buying Windows hardware (laptops, desktops, servers, etc.) if you want Linux to work on your computer. :) [this is the long-term solution: make Linux impossible for (at least a significant subset of the) hardware vendors to ignore so that hardware will work with Linux without the hassle of figuring out The Way Windows Does It.]

You said:
> when Windows has 90% of the market share for desktops and laptops you'll never convince Samsung, Gigabyte or ASUS (for example) to bother testing with Linux.They won't even notice the drop in sales if Linux users stop buying from them.

No, but smaller vendors like zareason and system76 will, and they'll get more clout with the ODMs and particularly those with write access to the BIOS who're in charge if they serve as the front for every Linux buyer.

This is how Apple does it. It's just that buying Apple to run MacOS is compulsory. Otherwise, you have idiots like Linux users who focus on short-term gains of an epsilon shinier hardware and sacrifice the ability for Linux to be a fully functional on it. It clearly works; Apple could do it even pre-iPod. We just need to put down the Windows hardware crack.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds