OS/2 2.11 SMP Woes

IBM OS/2 V2.11 for Symmetric Multiprocessing (OS/2 2.11 SMP) was released in mid-1994 in response to Windows NT and its SMP support. The package was nothing more (and nothing less) than OS/2 V2.11 with support for SMP hardware. It was intended primarily for server machines, not least because non-server SMP systems were nearly nonexistent in 1994.

OS/2 2.11 SMP was often shipped with high end servers, for example on IBM’s ServerGuide or Compaq’s SmartStart CD-ROMs (alongside Novell NetWare, SCO OpenServer, etc.). But a generic OS/2 2.11 SMP package had not been seen in the wild… until it appeared relatively recently (2020).

The included photos suggest that there was some kind of shrinkwrapped OS/2 2.11 SMP package, although in the absence of an actual box it’s hard to be sure. It is still unclear how exactly generic OS/2 2.11 SMP was sold and supported—although fixes for OS/2 2.11 SMP did exist, they do not appear to have been distributed through the usual public channels.

Knowing that OS/2 Warp Server Advanced SMP and Warp Server for e-Business work well enough, I thought I’d try OS/2 2.11 SMP in VirtualBox. Only that turned out to be much less than straightforward.

To simplify things a little, I set up the test VM with BusLogic SCSI emulation, since that allows the OS/2 CD-ROM support to work without modifying the boot floppies (the mid-1994 release was just a bit too old for ATAPI CD-ROM support).

Doing a full install failed to set up any SMP support at all, and I’m not entirely certain if that should have worked or not. In any case, I ended up with a more or less regular OS/2 V2.11.

Trying again and choosing selective installation, I found a “Symmetric Multiprocessing Support” checkbox—the one visible difference from regular OS/2 V2.11:

OS/2 2.11 SMP Installer

Clicking the checkbox brings up the following dialog:

Installing SMP support in OS/2 2.11

I tried a lot of different things, pointing the installer at actual PSD files (there were none in D:\OS2SE21). All of my attempts resulted in the following error message:

It just won’t install

It is not particularly difficult to discover that the PSD files are in the \OS2SE21\DISK_4\BUNDLE archive on the installation CD-ROM. Manually extracting the OS2APIC.PSD file and copying it to the root directory of the boot drive or to the \OS2 directory is also easy, as is adding the PSD=OS2APIC.PSD statement to CONFIG.SYS.

Sadly, that only results in OS/2 crashing hard very early on startup. But… why?

After analyzing the OS2APIC.PSD code a little, I found that it is not going to run on any SMP hardware made after 1994 or 1995. In short, the PSD refuses to install itself because it expects to find very old APIC hardware. There are likely multiple reasons why the old OS2APIC.PSD refuses to load.

The OS/2 installer actually works as designed, but the error handling leaves much to be desired. As far as I can tell, the logic is as follows: The installer is pointed at a directory containing one or more PSDs. OS/2 tries to load the PSDs one by one, looking for the one PSD which successfully loads. That is then copied to the \OS2 directory and added to CONFIG.SYS.

The trouble is that the error message is the same when no PSD is found, as well as when all PSDs refuse to load. Needless to say, that is not very helpful.

The solution is copying OS2APIC.PSD from Warp Server Advanced SMP or Warp Server for e-Business to a floppy and pointing the installer to that. The newer driver will load successfully, the installer will copy it and enable, and on the next boot, SMP support will be available:

OS/2 2.11 with 2 CPUs

The problem with “too new” APIC hardware is not new. Old MPS HAL versions for Windows NT have similar trouble. In the early days, Intel’s APIC hardware underwent quite significant changes between the 486 and Pentium, and finally more or less settled with the Pentium Pro. Some systems also insist on firmware providing MPS version 1.1 tables, rather than supporting the newer version 1.4 specification.

The hard crashes at boot-up are likewise not unique; for example Windows 10 has rather similar problems when it finds itself running on an unsupported CPU. In both cases, the error happens too early to be handled correctly, and only in situations that clearly weren’t tested (in the case of OS/2 2.11 SMP, manually installing an unsupported PSD is arguably a user error, given that the OS installer refused to do it).

All in all, the generic OS/2 2.11 SMP really does work, but requires a newer OS2APIC.PSD which can support slightly newer APIC hardware.

Update: After poking around some more, I think I now understand how the OS/2 2.11 SMP installer was intended to work.

The installer does try to install SMP support by default. It does that by trying to load by the PSDs on the installation media and installing the first one(?) which does not refuse to load. The dialog asking for a drive and path only comes up when the installer doesn’t find any suitable PSD. It is unsurprising (if sub-optimal) that the developers and testing focused on supported SMP systems and did not pay much attention to SMP systems that were not supported out of the box. If they had, the installation flow and error messages would probably be a lot clearer.

Further analysis also revealed the other reason why the original 1994 OS2APIC.PSD failed to install/function in VirtualBox. The code looking for the MP configuration structure starts by checking the EBDA (where it would be found), but looks at the EBDA only if the EBDA is located right after the end of conventional memory. That is not always the case with the VirtualBox BIOS.

It is unclear why the EBDA location check was implemented and I can’t think of a reason why it would be necessary. It is highly likely that the check caused problems with some BIOS implementations back in the day—because the 1996 OS2APIC.PSD shipped with Warp Server Advanced SMP relaxed the EBDA location check. That was in addition to relaxing the I/O APIC version check.

As hinted above, the old OS2APIC.PSD only loads on a system with an I/O APIC which has 15 interrupt redirection entries. That was the case with the original 82489DX APIC and with the 82379AB SIO.A southbridge, but the newer discrete 82093AA I/O APIC used with PIIX3/PIIX4 southbridges already supported 24 redirection entries and failed the check in the old OS2APIC.PSD. The 82093AA I/O APIC was used with many newer dual processor Pentium systems that started appearing in 1996, typically in conjunction with the Intel 430HX northbridge and PIIX3 southbridge.

Addendum: VirtualBox can emulate an old enough I/O APIC that passes the version check in the V2.11 OS2APIC.PSD iterations. This can be enabled as follows (command on a single line):

VBoxManage setextradata <vmname> VBoxInternal/Devices/ioapic/0/Config/ChipType 82379AB

As the chip type designation suggests, this will pretend the I/O APIC is the SIO.A model.

With this tweak and with the EBDA in the right place, OS/2 2.11 OS2APIC.PSD can work in VirtualBox. That includes an OS/2 2.11 SMP beta with kernel revision S.618 from April 1994, published on the OS/2 Developer Connection 4 CD-ROM.

Note that old versions of OS2APIC.PSD have a tendency to hang early during boot-up, when bringing up secondary CPU(s). This problem is caused by the PSD using delay loops that execute too quickly on fast CPUs. Later versions of OS2APIC.PSD are much more stable, since this was a problem with physical machines in the late 1990s already.

This entry was posted in IBM, OS/2, PC history, SMP. Bookmark the permalink.

22 Responses to OS/2 2.11 SMP Woes

  1. MiaM says:

    Semi-relevant side track:
    A machine/chipset/bios that might be worth testing, if it’s possible to emulate in PCem or similar, would be the HP Vectra XU 5/90 which is a SMP desktop computer that usually shipped with one or two Pentium 90 CPU’s. It’s known for being too old for most Linux versions to run out of the box, but for example NT4 runs perfectly without any patches.
    I think the chipset is 430NX “neptune”, according to some search result, but don’t quote me on that.

  2. vbdasc says:

    PCem appears quite dead right now, try the good folks at the 86Box project 🙂 However, 86Box already emulates a load of machines, so you will need to be quite persuasive to get someone to implement it… Of course, they accept patches that implement new machines, but only if the machine has some notability 🙂

  3. Michal Necasek says:

    The chipset is the least relevant thing actually. What matters is the CPU (local APIC) and I/O APIC, as well as the BIOS.

  4. vbdasc says:

    “The hard crashes at boot-up are likewise not unique; for example Windows 10 has rather similar problems when it finds itself running on an unsupported CPU. In both cases, the error happens too early to be handled correctly”

    Yes, this reminds me of how I wasted a few hours trying to install Windows 8.1 on a CPU without SSE2, getting some quite non-informative and misleading blue screens of death. C’mon, Microsoft, cpuid exists, you can at least handle such cases more gracefully.

  5. vbdasc says:

    @Michal Necasek:

    Isn’t the IO APIC controller a part of the southbridge, hence the chipset?

  6. Michal Necasek says:

    Often but not always, for example the PIIX3/PIIX4 southbridges had no integrated I/O APIC but supported an external one. The discrete 82093AA I/O APIC was used on a number of boards.

    Intel’s old 82378ZB SIO southbridge had fancy EISA style DMA support but no I/O APIC. The 82378AB SIO.A dropped the EISA DMA but added an I/O APIC. In the next generation, PIIX had no I/O APIC support at all while PIIX3 supported an external I/O APIC. The PIIX4 likewise had support for an external I/O APIC (the above mentioned 82093AA). The ICH soutbridges all(?) had an I/O APIC built in. I think that was when people realized that the additional interrupt lines on the I/O APIC reduce the need for interrupt sharing, and that using the APIC can be advantageous even with single-processor systems.

    ETA: The original 82489DX was also a discrete chip.

  7. Yuhong Bao says:

    Correction: SIO.A did not drop the EISA DMA, just limited it to 27 bit.

  8. Michal Necasek says:

    According to the datasheet, the 82379AB also dropped scatter/gather support and Type A/B/F fast DMA timings.

  9. Simon says:

    “the mid-1994 release was just a bit too old for ATAPI CD-ROM support”

    Too old?
    Maybe too new, too fresh, that’s you had in mind?

  10. Michal Necasek says:

    What I meant was that a 1994 release is too old to have ATAPI support included, whereas a 1996 release is not, given that ATAPI exploded in mid-1994 to 1995.

  11. vbdasc says:

    Windows NT 3.5 had ATAPI CD-Rom support in September 1994. Granted, this is a couple of months after the OS/2 2.11 SMP, but is still 1994.

  12. Michal Necasek says:

    ATAPI 1.2 came out in June 1994, same month as OS/2 2.11 SMP. Those few months made a difference.

    On top of that, OS/2 2.11 SMP was really meant for server systems… which in mid-1994 were highly unlikely to be equipped with an ATAPI CD-ROM.

  13. Fernando says:

    The generic version of OS/2 SMP that you checked, only supports APIC?
    I remember before MPS there were a few SMP non standard systems.
    P.S. Is always interesting reading your posts.

  14. Michal Necasek says:

    OS/2 2.11 SMP does come with about six PSDs for different SMP platforms. But good luck of getting hold of any hardware or even emulation besides MPS/APIC.

    As far as I can tell, once Intel had the APIC, there was no point in using anything else.

  15. JQW says:

    Banyan VINES also supported SMP servers back then – primarily on Compaq SystemPro and NCR server hardware, from VINES 4.xx.

    Installation floppies for the various VINES SMP variants have been lost – however there are some SMP installation files on the VINES installation CD-ROMs from VINES 6.00 onwards. On the 6.00 installation CD there’s binary files named /etc/mpcode.syspro, /etc/mpcode.ncr and /etc/mpcode/sse, which I presume do the same thing as the PSD files under OS/2. SSE were presumably a forgotten server manufacture. By the time VINES 8.50 appeared in 1998, there was also a file named /etc/mpcode.mps14.

  16. Hello.

    Just for reference of the part numbers that is this IBM announcement from 1996.
    There are 3 different part numbers for 2.11 SMP
    -83G7550 OS/2 for SMP 1-2 Processors
    – 83G8077 OS/2 for SMP 1-7 Processors
    – 83G8078 OS/2 for SMP 1-16 Processors
    And also some other part numbers to upgrade between the number of processors.

    The CD-ROM image used on this article says “for 1-2 Processors” which makes me think there are different media for the rest.

    https://www.ibm.com/docs/en/announcements/archive/ENUSZP94-0432

  17. Michal Necasek says:

    Yep. The question is, what did the box look like? Who sold it? How much did they charge for it? At best it would have been an extremely low volume product, again because the typical customer would get OS/2 2.11 SMP with their new multiprocessor server.

    The CPU limit is compiled into the PSD drivers (not the kernel!), so yes, the different variants had to come on different media.

  18. Michal Necasek says:

    OS/2 2.11 comes with the following drivers: OS2APIC.PSD, VIPERMP.PSD, EBI2.PSD, TRICRD.PSD, PROLIANT.PSD, WYSE.PSD, ALR.PSD. From the names alone it’s hard to guess how much overlap there was, besides OS2APIC being the equivalent of mpcode.mps14.

  19. MiaM says:

    Was such products even sold as boxes and whatnot?

    On one hand, expensive equipment usually came with expensive documentation and whatnot (not saying that it was good, just that it cost money to produce). I.E. various boxes and whatnot. But on the other hand, things that had a really small sales quantity might just had come in the regular large quantity box but with some adddendums. I.E. likely custom media (either additional media or separate distribution media) and not much more.

  20. I’m the one who runs that site (and dumped this)! I’ll check on the box when I’m at storage next time. iirc it’s a regular OS/2 box that just says OS/2 for SMP on the spine on a square label. If I can dig up a picture somewhere before getting there I’ll let you know.

  21. Michal Necasek says:

    Cool, thanks! Do you know anything about where the box came from?

  22. I actually got it from an estate of someone who bought a lot of surplus government stuff. Came along with the IBM Communications Manager/2s under the OS/2 Applications subdirectory. Wish I knew too, definitely an odd find.

    Somewhere I also have an official IBM OS/2 2.1 on CD-ROM. I should dig that up because that’s another rare find (from a thrift store).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.