The 80386 HLT instruction tells the CPU to stop executing instructions until a hardware interrupt occurs. This was traditionally the instruction performed by the operating system when it had no work to do, allowing the CPU to go into a low-power mode. (In modern times, operating systems use other instructions like MWAIT to go into even lower power modes when they have nothing to do, but those fancy instructions didn’t exist in 1995.)
A while ago, I discussed how Windows 95 intentionally did not use the HLT instruction when idle because there were multiple models of laptop which locked up unrecoverably when the CPU executed a HLT instruction. People wrote aftermarket components that performed HLT instructions on behalf of Windows 95 to get low-CPU behavior, with the added notation “I can’t believe Windows 95 is so stupid that it doesn’t have this feature built-in.”
I guess these people never got bug reports from customers saying “I installed your custom program, and now my laptop freezes up as soon as it boots. How do I uninstall it if my laptop freezes up at boot?”
And that’s the problem: The failure mode is a brick.
Windows 95 could have added detection for the systems that froze up on HLT instructions, but since there were many such systems, the risk was that by the time Windows 95 shipped, not all affected systems would have been identified. The fact that many systems were affected means that this was not an isolated case. We’re probably seeing the tip of a very fragmented iceberg.
Since the failure mode is a system that is unusable, the cost of a false negative was far too high. We just had to remove the HLT.
Was that the same problem that Wikipedia article about HLT instruction describes, mentioning “no-hlt” Linux kernel boot argument, or a different one?
In other words, these CPUs could be irreversibly damaged by certain instructions?
Or is it possible to repair these bricks, but only geeks can do it?
No CPU would have been damaged, it just resulted in a system freeze.
If the machine is put into a mode where it cannot do anything without opening it up and fiddling with hardware, then that counts as damage.
This includes any mode where you would have to do something like remove all power sources including the onboard battery. Since that’s often soldered onto the motherboard, particularly on laptops.
This sounds like the relevant laptop manufacturers cut some corners, not implementing a procedure for what they saw as something that would never happen.
But of course it would come back on the Windows people.
>How do I uninstall it if my laptop freezes up at boot?
Easy, you just re-install Windows
IMO there should have been a way to enable it under some ‘advanced options’ dialog somewhere, where it warns you it may lock up, and it immediately restarts when enabling it.
If it fails to startup successfully the next time (via writing something to disk before ever using an HLT on startup), it disables the option, and tells you why on the _next_ successful startup
If the HLT instruction had been located in a driver (or written into the kernel by such a driver when loaded), would it have been possible to boot into Safe Mode to unbrick the device?
Very interesting! Does anyone know how OS/2 solved the laptop issue, or was OS/2 just never used on a laptop in 1995?
In 1994, OS/2 exposed an issue in the first stepping of the 486 DX4 processor. OS/2 used the HLT instruction when idle. While sleeping during HLT, bits in the cache could flip. (Not all processors were affected, and once the problem was discovered, additional testing was added to screen out the affected processors until the problem was fixed with a new stepping.)
It seems like a well placed HLT at the end of the WIN95 installation process could have been a good way to suss out if the hardware would hang. At most issuing the HLT, with say onscreen text of “Rebooting System”, would result in the user would manually rebooting the system after a few minutes.
“Unrecoverably” is the key word here. The laptops would freeze forever with no recovery possible. This includes reboots.
@Sigge: “Was it a brick or was it a brick until restart?” It was a brick until restart, but it restarts into a brick! The OS boots into a brick.
Was it a brick or was it a brick until restart? It’s a bit unclear, but it’s highly unlikely a reboot wouldn’t fix the issue
Bad decision.
Solution: enable HLT during hardware detection. If it locks up, treat it the same way every other driver lock-up is treated: that driver won’t be used.
(In case somebody doesn’t know how this is solved already: the hardware detection writes a marker of what test is being performed before testing it, so on reboot it knows to fail that test and resume.)
What if the CPU never hands control over to the OS?
It sounds like that’s what happened. A reboot (including turning it off and on again) just made the CPU HLT again.
I wonder if it even looked at the BIOS.