OS/2 2.0 LA and “Large” IDE Disks

Attempting to boot OS/2 2.0 LA (Limited Availability) on many systems built in the last 20 years often results in the following crash:

The trap screen claims there was an exception (Trap 0 or division overflow) in device driver A:, but that’s not quite true. The crash occurred in the disk driver (DISK01.SYS) which handles both the A: floppy drive and the C: etc. hard disks.

The register dump indicates that this wasn’t a division by zero (no general-purpose register contains a zero) but rather a division overflow. The driver is using 16-bit division and the result does not fit into a 16-bit register. Without analyzing the problem in detail, it is fairly clear (based on the register contents) that the driver is calculating fixed disk geometry parameters.

The problem was hardly new in OS/2 2.0 LA. Attempting to boot IBM OS/2 1.3 EE on the same system results in the following trap screen:

And going a bit further back, Microsoft OS/2 1.2 produces this:

This might be surprising (why would a 32-bit OS have the same problem as its 16-bit ancestors?) until one realizes that OS/2 2.0 LA (October 1991) used more or less exactly the same 16-bit disk driver, DISK01.SYS, as OS/2 1.3 EE (1990).

While the GA (General Availability) release of OS/2 2.0 still utilized 16-bit disk drivers, the storage subsystem was almost entirely unrecognizable. OS/2 1.x generally used monolithic disk drivers which implemented low-level device support as well as OS-level block device interface in one module, but OS/2 2.0 GA was significantly different.

The notable OS/2 1.x exception was Microsoft’s OS/2 1.21/1.3 which used LADDR (pronounced ‘ladder’), or LAyered Disk DRiver, architecture. In the LADDR architecture, a large chunk of the disk driver was generic, with relatively small hardware-specific modules (much like Microsoft’s later ‘miniport’ model). The hardware-specific modules had a .BID extension (ESDI-506.BID, AHA154X.BID), the device-specific modules used a .TSD extension (DISK.TSD), the over-arching driver was IOS1X.SYS. Microsoft developed the LADDR model as a way to improve storage support for its LAN Manager server.

OS/2 2.0 GA implemented a model somewhat similar to LADDR, with a generic OS2DASD.DMD module and hardware-specific IBM1FLPY.ADD, IBM1S506.ADD, etc. modules. A notable addition was the fallback IBMINT13.I13 driver which used the BIOS to access the disk. Which is not to say that OS/2 2.0 GA did not have problems with larger IDE disks… but it did handle drives up to about 2GB in size. Due to the history of the IDE interface which evolved slowly but steadily, limitations in older operating systems are inevitable.

But back to the original problem. How to avoid the crashes? In a virtualized environment, use a 500MB or smaller disk. That will avoid any issues with discrepancies between logical (BIOS) and physical (IDE) geometry, and will keep the disk size small enough to avoid overflows.

With a physical system, that can be tougher as a working 500MB disk might be hard to find. Different disk sizes will produce different results. What matters is not only the disk size but also the partition table contents. Wiping the partition table and letting OS/2 partition the disk may help.

Using SCSI disks sidesteps this particular issue, in exchange for a whole bunch of new ones… starting with how to find a suitable driver. But that’s an entirely different problem.