Your PC still has a keyboard controller interface from 1984, and Linux keeps it as its second way to reboot

The firmware inside the keyboard controller of the 1984 IBM PC/AT wasn't publicly dumped until 2008, more than two decades after the AT shipped, and was subsequently disassembled and reverse-engineered. By then, the interface IBM had created around that controller had become a fixture of the x86 PC, even as the original physical 8042 gave way to compatible implementations in other chips. That chip, the Intel 8042, wasn't just a keyboard controller, either; IBM connected output-port bit 0 to the AT's system-reset circuitry. In that system, writing a single byte to the right I/O port could force the processor to reset. And the same software-visible interface and reset command still survive on modern x86 platforms, more than forty years later. Granted, the 8042 reset isn't the main way your computer reboots anymore, but remarkably, it's still the second thing the Linux kernel normally tries. Linux attempts ACPI first, then the keyboard-controller reset, before falling through to other mechanisms if the machine stubbornly stays alive. The reason it's kept around is complicated, and the fact that nobody has been able to cut that connection in forty years is, in its own way, a pretty ridiculous thing in the modern computing landscape. The 8042 was never meant to be a keyboard controller It was a victim of circumstance The Intel 8042 is a member of the UPI-42 family of programmable peripheral controllers, derived from Intel's MCS-48 microcontroller architecture. On the IBM PC/AT's motherboard, IBM programmed it with firmware that made it function as the keyboard controller, receiving data from the keyboard and exposing it to the rest of the system. It wasn't a keyboard-specific chip; it was a programmable peripheral controller that IBM adapted to the job. IBM, though, put the controller's spare output pins to work. The output port on the 8042 had eight bits, and two of them ended up controlling critical motherboard functions. Bit 1 managed the A20 gate, a workaround that preserved compatibility with 8086 software relying on address wraparound past one megabyte, and bit 0 was connected to the system-reset line. Writing a byte to the output port with bit 0 low would assert reset and keep the processor there until the signal was released. There was an especially useful reason for that connection, though. The 80286 had a notorious design limitation: once it entered protected mode, there was no normal architectural instruction for switching it back into real mode. IBM therefore provided a way for software to reset the processor and arrange for execution to resume afterward instead of performing an ordinary cold boot. The keyboard-controller reset became one of the standard ways for protected-mode software to make that transition. There were two ways to trigger the reset through the 8042, and only one of them was safe. Writing 0xFE to I/O port 0x64 told the 8042 to pulse output-port bit 0 low for approximately six microseconds, briefly asserting System Reset. The controller then released the pulse, allowing the CPU to restart from its reset vector. That's the safe form of the mechanism that survives as the conventional KBC reset command. The dangerous version, meanwhile, wrote 0xD1 to port 0x64 and then a data byte to port 0x60 where bit 0 was zero. That held the system-reset output low, and the IBM PC/AT Technical Reference warned that bit 0 should never be written as zero. This is a more blunt form of reset; the processor remains held in reset, so it can no longer execute anything that would tell the 8042 to release the line. An external reset or a power cycle is then required. The 8042 isn't the only piece of ancient PC hardware whose interface survived this long. The 8259 Programmable Interrupt Controller and the 8254-style Programmable Interval Timer come from an even older part of the PC lineage, and compatible implementations of both remain documented on modern Intel platforms. Arrow Lake, for example, still documents internal 8259s and an 8254 timer subsystem. The original chips are gone, but the interfaces they established are still part of the platform. Crashing the CPU was faster than asking the keyboard controller Who needs to safely shut down, anyway? The keyboard-controller reset had a problem: it was slow. Software had to wait for the 8042 to become ready before issuing the reset command, and the controller itself was vastly slower than the CPU it was resetting. Contemporary accounts describe the process as taking hundreds of microseconds, with the exact delay depending on the machine. Developers discovered another way: deliberately triggering a triple fault. If an exception occurs while the processor is already trying and failing to invoke another exception handler, it can escalate to a double fault; if the processor then cannot invoke the double-fault handler either, the 286 enters a shutdown cycle. Motherboard hardware can detect that shutdown cycle and assert RESET. One particularly neat way to provoke it is to load an interrupt descriptor table with a zero-length limit and then trigger an interrupt. This avoided waiting on the keyboard controller and was measurably faster. Robert Collins, documenting the technique and its history, described triple-fault reset as roughly one-third faster than the keyboard-controller method, while noting that the exact timing varied by machine. By the time Intel released the 80386, the processor could return to real mode by clearing the protected-mode enable bit in CR0. But by then, both the keyboard-controller reset and deliberate triple faults were established parts of PC software behaviour, and both mechanisms survived long after their original purpose became obsolete. Funnily enough, both methods still survive in the Linux kernel to this day. The keyboard-controller reset is tried near the beginning of the normal fallback sequence, while a triple fault is one of the kernel's last-resort reset methods. And both have been there for decades. The 8042 reset still works, but it's fallback number two We have better ways, now The Linux kernel's reboot strategy is documented in a comment in the source code itself. With the normal ACPI reboot path, it tries ACPI first, then the keyboard controller. If the machine survives, it gives ACPI another attempt, then tries the keyboard controller again, followed by EFI and the BIOS reboot path. The state machine can then continue into the chipset reset control register at port 0xCF9 and, eventually, a deliberate triple fault. If even that somehow returns, it loops around and tries the keyboard controller again. On systems whose ACPI reset register points at 0xCF9, the ACPI path and Linux's explicit chipset-reset path ultimately reach the same reset-control register. The keyboard-controller path is a separate legacy interface that predates the chipset reset-control register by decades. Linux writes 0xFE to port 0x64 up to ten times per attempt, polling the status register before each write until the controller's input buffer is ready. It isn't merely dead compatibility code, either; Linux still contains machine-specific quirks that select keyboard-controller reboot on systems where other reset mechanisms are unreliable. On the Windows side, things are more complicated. The ReactOS project, a clean-room reimplementation of the Windows NT-era HAL, contains a function called HalpWriteResetCommand that writes 0xFE to port 0x64 with the comment "Generate RESET signal via keyboard controller." ReactOS uses this mechanism in its NT-compatible x86 HAL, showing that the keyboard-controller reset remains part of the conventional NT-compatible PC design. Whether modern Windows still contains or uses an equivalent fallback is harder to establish without Microsoft's current HAL source. The A20 gate is gone; the CPU reset never left Though it's been effectively deprecated Bits 0 and 1 of the 8042's output port controlled two very different things. Bit 1 handled the A20 gate, which let the 80286 maintain compatibility with software that relied on 8086-style address wraparound. Bit 0 controlled System Reset. They happened to share the same byte in the same chip's output register, but they were always independent mechanisms at the hardware level. By 2013, Intel had effectively deprecated the A20M# pin. Its software developer manual from June of that year describes the functionality as primarily used by older operating systems, and not used by modern ones, while also warning that the pin may be absent on newer Intel 64 processors. The keyboard-controller interface, though, never disappeared. Intel's Arrow Lake-S PCH documentation still decodes I/O ports 0x60 and 0x64 as the Keyboard Controller interface, forty years after the PC/AT introduced them, and forwards those accesses externally over eSPI. The physical Intel 8042 is long gone, replaced by embedded controllers, Super I/O chips, and other compatible implementations, but software can still use the same legacy interface that Linux's keyboard-controller reset path expects. The physical controller and IBM’s particular firmware have long since given way to compatible implementations, but the interface they helped establish became part of the PC platform. Ports 0x60 and 0x64 are still explicitly documented as Keyboard Controller addresses in Intel's modern PCH documentation, and Linux still knows how to send a reset command through that interface. It sits near the front of a fallback chain where it almost never needs to succeed, because newer reset mechanisms normally work first. But PC platforms have continued carrying the interface forward because somewhere, somehow, old software or broken hardware may still depend on it. The literal wire disappeared long ago, along with the original 8042 itself, but the interface didn't. More than forty years after IBM gave a keyboard controller the ability to reset an 80286, modern PC hardware still recognises its ports, and the Linux kernel still knows exactly what 0xFE written to 0x64 means.