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.

32 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).

  23. Nathan Anderson says:

    @Michal,

    I was about to respond to mention that I was pretty sure somebody had already figured out that you can use the PSD from Warp Server on 2.11 SMP. I thought it might have been virtuallyfun / Jason, but then I started searching around and…found it was you who had done so in your original article about 2.1 and 2.11. πŸ™‚

    @Michal and @Martin,

    Are copies of all 3 versions of 2.11 SMP (with the different processor count limits) circulating? If so, has anybody tried to compare OS2APIC.PSD from all 3 releases to see if the CPU count limit is just, like, a single byte difference?

    @Compgeke,

    How exciting! I’ve been curious to see a 2.11 SMP box for a while, assuming such a thing even existed, so it’s nice to have confirmation. As for OS/2 2.1 on CD-ROM, I hate to break it to you but that is hardly rare. πŸ™‚ Now if, on the other hand, you had said *2.0* on CD-ROM, that would be a different matter…

  24. Michal Necasek says:

    I had known that the newer PSD can be used with 2.11 SMP all along, but I wanted to understand why the old PSD wasn’t working.

    I have not seen other copies of 2.11 SMP. But yes, it’s compiled into the PSD and it probably would not be hard to patch out the check.

  25. Robert says:

    I worked in the IBM PC server development group in the 90’s, in software tools development, and we had these OS/2 boxes. And from what I recall it used the regular 2.11 box with a simple sticker on the spine. Nothing special basically.

    In 1997, I actually had had a dual-cpu PC Server 325 (late model test unit that was no longer needed) as a desktop running OS/2 Warp Server Advanced SMP with 256MB RAM. I did plug in a Matrox Millennium graphics card as the integrated graphics were very poor, but it made for a very fast desktop!

  26. Michal Necasek says:

    I once installed OS/2 2.11 SMP on an IBM PC Server 704. It was a server the size of a small fridge, with four Pentium Pro CPUs. I believe it was basically a rebadged Intel server. It had lots of disk bays and it was loud… but it sure was fast!

  27. Robert says:

    The 704 was indeed a rebadged server. Now the PC Server 720 was the real IBM developed server. Up-to 6 Pentium CPU, which could even run at different clock speeds. And of course it supported MCA cards.

    When I started working there, the “PC Server” product line was just introduced, but there were still tons of PS/2 servers around (incl the dual-cpu 195 type).

  28. Yuhong Bao says:

    I wonder why Fast Ethernet (100Mbps) cards were never common for MCA.

  29. Michal Necasek says:

    By the time Fast Ethernet arrived, MCA was clearly on its way out. I assume it was a purely marketing problem, not a technical one.

  30. Yuhong Bao says:

    I wonder a lot of the problem is that it would probably have required ASIC chip fabrication.

  31. Lars says:

    I can add something to the PSD sample code that was released, in particular to the ALR.PSD sample code listed in the SMP 2.11 Reference and the PSDHLP_CALL_REAL_MODE PSD helper function that it uses.

    It makes use of the PSDHLP_CALL_REAL_MODE in order to gather information if the system is an ALR system.
    The code is simple enough, PSDHLP_CALL_REAL_MODE invokes a helper function in the PSD to do the job.
    However, the sample (and in particular, the makefile) implies that that helper function code could be anywhere in memory which is not true.
    In fact, PSDHLP_CALL_REAL_MODE will actually switch the system into real mode which as a consequence means that the user function will need to be PHYSICALLY located below the 1 MB address line.

    When I wrote my own simple PSD to print out a string on screen on bootup and using the real mode BIOS to do so, I actually had to allocate memory below the physical 1 MB address line, copy the user function to that memory and have it execute from there.

    I would think that under SMP 2.11, all PSD code used to be loaded below the physical 1 MB address line while on current SMP this is definitely not the case. In short any old PSD written for SMP 2.11 and making use of the mentioned PSDHELP will likely crash the current SMP system implementation.

  32. LightElf says:

    @Lars
    Mastrianni’s book explicitly states that “Objects [of PSD] are loaded in low physical memory to allow the use of real mode or bi-modal code”.
    https://mastrianni.net/wp-content/uploads/2018/09/thirded.pdf

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.