There was a post on the oldnewthing blog about this but I can’t immediately find it.
There was a post on the oldnewthing blog about this but I can’t immediately find it.
On the other hand, HLT was commonly found in the DOS software of the time, often for quick and approximate timing delays, and I don't remember any specific discussions about that causing problems, so I'm still not sure what the true problem is; my guess is that the combination of protected mode, which increases power consumption over real mode, and the sudden drop in current draw caused by a HLT, was enough to cause marginal power supply circuitry to fall out of regulation, similar to how stress-testing when searching for a stable overclock will sometimes crash the machine when it ends, not when it starts. On the more digital side, interactions with SMM might also be relevant: http://www.rcollins.org/ddj/Mar97/Mar97.html
I wonder how this works. How do you safely check for an instruction that "locks ups unrecoverably" on some hardware? Will Linux hang on boot on such systems? That is still better than hanging randomly later, but I can see why Microsoft didn't want to go for that approach.
EDIT:
The check in Linux literally just called hlt a bunch of times and hoped it didn't crash. There was no recovery in case it failed (note how there's no code path to print anything else than "ok"). Searching for "checking hlt instruction" you can actually find people asking on forums why their boot stoped at that point. The check has been removed in recent kernels, so I had to go back in history a bit to find it.
https://github.com/torvalds/linux/blob/521cb40b0c44418a4fd36...
Yet Windows 95 has a message in its hardware detection dialog which tells you to restart the computer if it stops responding for a long time while it's detecting hardware --- and I believe it writes to the disk its progress, so it'll remember where it was and skip it the next time.
One wonders why neither MS nor Linux did that for HLT. Linux has a no-hlt boot parameter to disable its use.
> If this fails, it means that any user program may lock the CPU hard. Too bad.