Method 6: return to 16-bit mode, call interrupt 0x19 (not if you're on efi).

Method 7: return to 16-bit mode, set cs to 0xf000 and jump to 0xfff0.

Linux used to use method 6, but it wasn't reliable either. Something tells me returning to 16-bit mode might not be possible for some hardware / driver combinations.

Method 7 is available for 32-bit systems, and actually pretty reliable. But going from 64-bit to 16-bit just to reboot is more pain than anyone really wanted to go through.

Jumping to the BIOS is not a reliable reboot method either (method 7). Because the BIOS assumes hardware in a hardware-reset state, and the OS left it in some other state.

Tried to get an OS on a PC to soft-reboot, failed, because it is not actually possible to return all hardware to the reset state in some cases - they have an initial power-on state and once programmed can never return there unless hard-reset.

And why does the BIOS require hardware in the hard-reset state? Because a BIOS is never tested in a soft-reset scenarios, because Windows doesn't require it. And "if you haven't tried it, it doesn't work".

Note that this way of rebooting was common in DOS though.

Could you explain in more detail how these trigger a reboot? From writing a 32-bit kernel I understand how the triple fault method is supposed to work, for example, but would love to know a little more about these methods.

int 19 should just execute code in the BIOS that triggers a reboot. Setting CS and jumping is re-entering the BIOS at the same entry point as at power-on. The BIOS should then reinit all the hardware.

I don't know if anyone else remembers, but I think it was either Windows 95 or Windows 98 which, after selecting shut down, the eventual result would be a message that said, "It is now safe to turn off your computer." I remember thinking it was magic when the computer would actually turn itself off at this point.

This article provides a good explanation for why that behavior was necessary.

No, that was a completely different issue. Before ATX the power supply could not be controlled by software at all—it only had a mechanical switch, often near the back of the machine rather than in front, because that's where the power supply was.

This article is about rebooting, as in resetting all the hardware without turning off the power. The original IBM PC had a well defined way to do this, but after decades of clones and clones of clones there's no longer any one method that's guaranteed to work on any machine.

Yup, I remember that. IIRC when this screen was displayed, the system was actually at a DOS prompt, just not in character mode. You could type "win" to restart windows for instance, and I think there was some magic command to reset the display adapter and get a working DOS prompt.

Power off uses APM or ACPI and is not related.

"How to shut down a PC" no mention of Linux, but apparently that is the topic.

But since it's not mentioned in the topic, it's going to come up. Personally I use a batch file and SysInternals to shutdown (after forcing bad-behavior apps to exit).

Sounds like you need a SysInternals for Linux??

The software that you use on top of your OS to ask your OS to reboot is irrelevant. We're talking about what the OS has to do to the hardware to get it to reboot. The blog post even notes that Linux 3.0 will be attempting to mimic the kludgey way in which Windows tries to get your machine to reboot.

It amazes me that this sort of behavior still hasn't been standardized and agreed upon by all PC and component manufacturers.

Reality is that in areas of poor standardisation, vendors will test against Windows and ship it if it works. You could argue for a cross-vendor compliance testing suite, but if the behaviour of Windows varied from that then people would still need to match the Windows behaviour because that's where the market is.

So for all practical purposes, the behaviour is standardised. It's just embodied in the behaviour of Windows rather than anywhere useful.

FWIW, the fact that it's standardized against Windows makes Windows kernel developers' lives suck too - any change can break some dumb device that only actually worked purely by coincidence against XP SP1 or some ancient version

I think that the other issue is the culture around(and design) *nix and BSD systems, where a reboot is generally only done when very bad things happen to the system, and nothing else can correct it. Often, there are a lot of other things going on that prevent the system from gracefully rebooting.

So hardware vendors might test a "standard" reboot, where nothing is broken, and the OS is in a stable state. Unfortunately, that probably isn't the case where most required reboots occur.

The behavior is standardized to a degree that it works for Windows, but according to your article Windows does its own poking around for the reset. It would be nice if there was one established protocol for resets rather than any poking around at all.

I guess this was the point of your article though.

Just type SYS 64738.

Wow, that takes me back. Nicely done.

My machine used RAND USR 0

PR#6

Wow - that's very interesting. So, what do most operating systems (aside from Apple presumably) normally do to get a consistent reboot?

Are they probing the hardware at install time? Do they just have a "table of things to try" the first time you reboot and then use the "successful thing" from then on?

Most operating systems fail on various bits of hardware. Windows uses the ACPI vector, then tries the keyboard controller, then the ACPI vector again, then the keyboard controller again, and then just stops.

I'm surprised the triple fault method doesn't reliably work - I thought that processors were guaranteed to restart if you do this; I suppose it doesn't guarantee that other components get reset in the same way.

Man, I love my ARM Cortex chips. I can just call NVIC_SystemReset()

Was there ever a computer as ugly as the IBM-PC?

I imagine even the Commodore 16 could reboot itself reliably.

An actual IBM-PC could reliably be rebooted using the keyboard controller (as mentioned in the article). The issues come with IBM-PC "compatible" machines. I'm sure commodore would have the same problem if anyone had bothered to clone them.

To be more precise, an IBM PC-AT. It is closely related to the A20 line enable.

Why should anyone need to mess with the A20 line and the keyboard controller to simply reset a computer?

Well, you do need to turn on A20 so it will jump to right address, but if you are in protected mode it should already be on.

Isn't that kludgy? I mean, using a keyboard controller (in effect, a second computer) to reset the one you can't?

The reason was that IBM bought the rest of the chips "as they were" from Intel, so all the logic that they made themselves ended in the in-house keyboard controller. x86 had an external interrupt line for reset, and an io pin in the keyboard controller was tied to this. That was a reasonable way to get true hard reset back then.

And what I meant by related was that another pin in the same keyboard controller was tied to the A20 gate, so it was toggled in a similar way.