The 25-Year-Old Bug That Still Breaks Modern PCs

The PC industry's most persistent design flaw has struck again, and this time it took down a cute little Japanese tablet PC that should have been perfectly capable of running modern Linux distributions. The culprit? A hardware quirk from 1982 that continues to haunt system designers and bootloader developers more than two decades later.

The story begins with the Intel 8086 processor, a 16-bit chip with a 20-bit address space that could theoretically access up to 1MB of memory. However, the segmented memory architecture created an interesting side effect: programmers could construct addresses that wrapped around past the 1MB boundary back to the beginning of memory. Rather than being a bug, some clever (or lazy) developers turned this into a performance optimization, avoiding the costly operation of loading segment registers.

When Intel introduced the 80286 with its 24-bit address space, this wraparound behavior became problematic. Addresses that previously wrapped now pointed to actual physical memory locations, breaking code that relied on the old behavior. IBM's solution was both elegant and infuriating: they added a hardware gate that controlled the 21st address line (A20), defaulting to keeping it tied low to maintain compatibility with the old wraparound behavior.

The truly bizarre part? IBM connected this gate to a spare pin on the keyboard controller. To enable full 24-bit addressing, you had to write specific commands to the keyboard controller—a solution that made sense in 1984 when every component needed to justify its silicon real estate, but became a nightmare for future compatibility.

Fast forward to 2009, and this ancient design decision is still causing problems. Modern PCs emulate this keyboard controller behavior, but implementation varies wildly. Some systems work perfectly with any A20 enabling method, while others require specific approaches or fail entirely. The Kohjinsha SC3 tablet that sparked this investigation is a perfect example of how this old bug can bite even modern hardware.

When attempting to install Fedora on the device, everything would proceed normally until the reboot. Grub would load the kernel and initramfs, jump to the kernel, and then hang mysteriously. The problem was particularly puzzling because booting from the live CD's "Boot from local drive" option worked perfectly—isolinux was clearly doing something different than grub.

The breakthrough came when switching to OpenSuse's version of grub, which had a smaller set of patches and a more paranoid approach to A20 enabling. Instead of trusting the BIOS's claim that the A20 gate was enabled, Suse's implementation explicitly tested whether the gate worked by writing values to addresses that should differ only if A20 was actually enabled. If the test failed, it would fall back to other methods.

The Kohjinsha's BIOS had lied about successfully enabling A20, leaving it disabled. Grub, trusting the BIOS, copied the kernel and initramfs to what it thought was RAM but was actually address space that wrapped around to the same locations. When the kernel tried to access what it expected to be distinct memory regions, it found garbage and crashed.

This isn't just an isolated incident. The Intel Macs famously don't implement the BIOS A20 enabling call at all, instead returning a failure code. They also lack a legacy keyboard controller, so attempting the keyboard controller method causes grub to crash. The magic IO port approach works instead—another example of how even Apple's x86 systems aren't truly "PC compatible" in the traditional sense.

The persistence of this problem highlights a fundamental truth about the PC industry: backward compatibility trumps all other considerations. For 25 years, hardware designers and software developers have been building workarounds for a hardware quirk that should have been eliminated in the 1980s. Every new PC still carries the burden of emulating a 1984 IBM design decision, complete with all its quirks and failure modes.

What makes this particularly frustrating is how easily it could be solved. Modern systems have no need for 16-bit real mode compatibility, yet we continue to emulate it perfectly. A clean break—a PC that simply doesn't support the old behavior and provides a modern, well-documented interface for bootloader authors—would eliminate entire classes of boot failures. But the fear of breaking something, somewhere, keeps us chained to these ancient design decisions.

The Kohjinsha SC3 story has a happy ending: a simple patch to make grub more paranoid about A20 enabling fixed the boot problem. But it's a reminder that even in 2009, we're still debugging hardware decisions made when Reagan was president and the IBM PC was the cutting edge of personal computing. Sometimes progress means knowing when to stop supporting the past—a lesson the PC industry still hasn't learned.