My dual Pentium III box dual-boots OS/2 Warp Server for e-Business (WSeB) and Windows 2000 from a single 60GB SSD, using OS/2’s Boot Manager. WSeB’s Logical Volume Manager (LVM) and Windows 2000 each have their own ideas about partitions and the active partition, so here’s the layout I used and the places where Windows quietly breaks Boot Manager.

LVM basics that matter here

From IBM’s Redbook Inside OS/2 Warp Server for e-business (SG24-5393):

• Compatibility volumes are plain one-partition volumes that other operating systems can see. They can be FAT, HPFS or HPFS386, not JFS, and the OS/2 base system must be installed on one.
• JFS isn’t bootable in WSeB, so JFS is for data volumes only.
• A volume can be bootable (listed in the Boot Manager menu) or startable (the active partition). Only one partition can be startable. When Boot Manager is installed it’s the startable one, and setting any volume startable disables Boot Manager.
• WSeB boots using the enhanced INT 13h services, so the old 1024-cylinder boot limit is gone as long as your BIOS supports them.

The layout

I created every partition with OS/2’s LVM, and let Windows Setup only format the one meant for it:

Partition	Type	Size	Purpose
Boot Manager	primary	~8MB	boot menu
WSeB	primary, compatibility volume, HPFS	4,000MB	OS/2 system
Windows 2000	primary, compatibility volume, NTFS	16,000MB	Windows system
Data	logical (extended), LVM volume, JFS	25,000MB	OS/2 data
Shared	logical (extended), compatibility volume, FAT16	2,047MB	readable by both OSes
(unpartitioned)		~10GB	left free on purpose

Some notes on the choices:

• The FAT16 volume stays just under 2GB so both systems can read and write it. It’s the easy way to move files between them.
• The unpartitioned space is for the SSD. Nothing from this era sends TRIM, so leaving some of it unused gives the drive room to manage wear and garbage collection.
• Never convert the disk to a Windows “dynamic disk.” OS/2 can’t read it, and it would wreck the LVM setup.

Installing Windows 2000 second

I installed WSeB first (see Installing OS/2 Warp Server for e-Business on a VIA 686B board), with the Windows partition already created and added to the Boot Manager menu. Windows 2000 Setup then refused to install to that partition. With Boot Manager as the active partition and the Windows volume merely “bootable”, Setup wasn’t having it.

What worked:

1. In LVM, set the Windows 2000 compatibility volume startable. This disables Boot Manager, as described above.
2. Install Windows 2000. Setup should only format the existing partition. Don’t let it create or delete anything.
3. Make Boot Manager startable again, and check that both systems are still on its menu (re-add them as bootable if not).

Step 3 needs OS/2’s LVM, but you can’t boot WSeB while Windows’ partition is active. Boot the WSeB install CD, press F3 at the prompt for an OS/2 command line, and run LVM.EXE from CD1’s OS2IMAGE\DISK_6 directory (it needs LVM.DLL and LVM.MSG from the same place). In the physical view, set the Boot Manager partition startable.

One more thing to watch in Windows Setup: booting the Windows CD bypasses Boot Manager, so Setup sees every primary partition. The WSeB HPFS partition can take C: and push Windows to a different letter, which is then fixed for the life of the install. Check the drive letter on Setup’s partition screen before you continue.

Things in Windows that break Boot Manager

Anything on the Windows side that touches boot setup tends to make the Windows partition active again, which silently disables Boot Manager. The next boot goes straight into Windows. The ones I’ve hit or would expect:

• Installing the Recovery Console (winnt32 /cmdcons). This one caught me after the install.
• fixboot / fixmbr in the Recovery Console
• Disk Management’s “Mark Partition as Active”
• A Windows reinstall or repair install

The fix is the same every time: install CD, F3, LVM.EXE from DISK_6, and set Boot Manager startable. It’s worth keeping that CD next to the machine.

Related: if you want Windows 2000 on both CPUs of a board like this, see Moving Windows 2000 from a uniprocessor HAL to multiprocessor.

Windows 2000 Setup on my dual Pentium III board (Asus CUV4X-D, VIA 694X / 686B) would only finish with the uniprocessor “Standard PC” HAL. Getting from there to both CPUs took three separate fixes, and each one only revealed the next problem. Here’s the sequence that worked, plus a way to test the multiprocessor kernel without risking the working install.

How it started

• With Setup’s default HAL it hung at “Starting Windows 2000.”
• Choosing MPS Multiprocessor PC with F5 gave STOP 0x000000C5 (0x4, 0x2, 0x1, ...) DRIVER_CORRUPTED_EXPOOL.
• Choosing Standard PC with F5 worked.

A side lesson: I spent a while testing RAM because of that 0xC5. What settled it was getting the identical STOP, with the same parameters down to the address, with a different single DIMM that had passed Memtest86+. Flaky RAM doesn’t fail at exactly the same place each time. A deterministic crash points at software or configuration.

The plan was to install on Standard PC, add SP4 and the VIA 4in1 drivers, then switch to the multiprocessor HAL. OS/2 Warp Server (on the same machine) ran SMP fine, so I knew the second CPU and its socket were good.

Step 1: test the MP kernel from boot.ini first

Rather than switching HALs in Device Manager and hoping, I added a second boot entry that loads the MP HAL and kernel by name. Extract SP4 (W2KSP4.EXE -x), copy halmps.dll and ntkrnlmp.exe from its i386 folder into %windir%\system32 (they’re compressed as halmps.dl_ and ntkrnlmp.ex_, so unpack them with expand, e.g. expand halmps.dl_ halmps.dll), and duplicate your existing boot.ini line with two extra switches:

multi(0)disk(0)rdisk(0)partition(N)\WINNT="Windows 2000 MP test" /fastdetect /HAL=halmps.dll /KERNEL=ntkrnlmp.exe

(Use your own partition(N), copied from the existing line.) If the test entry crashes, the normal entry still boots the untouched uniprocessor setup.

My first try crashed with STOP 0x0000001E (0xC0000005, 0x00000001, 0x00000000, 0x00000001), an access violation at address 1, which means execution jumped somewhere wild.

Step 2: disable MPS 1.4 in the BIOS

The CUV4X-D BIOS has an MPS 1.4 support option. With it Disabled, the 0x1E went away. I can’t tell you exactly why. My guess is that the BIOS’s MPS 1.4 tables and Windows 2000’s MPS HAL don’t agree on this board. Leave it disabled. OS/2’s SMP kernel is happy either way.

That got further, to a new error:

STOP: c0000249 {UP/MP Image Mismatch}
The image ntdll.dll has been modified for use on a uniprocessor system...

Step 3: swap in the MP versions of three files

When SP4 is installed on a uniprocessor HAL, it installs uniprocessor builds of a few user-mode and win32k files, from the i386\UNIPROC folder in the service pack. In those copies the x86 LOCK prefixes (0xF0) have been patched to NOP (0x90), which saves a little time on one CPU but is unsafe with two. The MP kernel checks for this and refuses to run them.

SP4’s update.inf lists which files these are, in [Uniprocessor.Kernel.Files] versus [Multiprocessor.Kernel.Files]. For SP4 the set is:

• kernel32.dll
• ntdll.dll
• win32k.sys
• winsrv.dll, which is also listed, but SP4’s UP and MP copies are identical, so it doesn’t need replacing

Take the MP versions from the extracted SP4: the regular i386 copies, not i386\uniproc. ntdll.dll is stored as is; kernel32.dl_ and win32k.sy_ need expand. The MP versions also run fine under the uniprocessor kernel, so swapping them doesn’t break your normal boot entry. They’re in use while Windows runs, so the swap has to happen from the Recovery Console. I staged them from Windows first:

1. From Windows, copy the three MP files to %windir%\MPFILES, and back up the current ones to %windir%\UPBAK.
2. Boot the Recovery Console and copy each file from MPFILES over the one in system32.
3. Reboot into the MP test entry.

That did it. Windows 2000 came up with two CPUs in Task Manager.

Step 4: make it permanent

After a soak test on the boot.ini entry:

1. In Device Manager, open Computer, choose Update Driver, show all hardware, and pick MPS Multiprocessor PC.
2. Reboot, then reinstall SP4 so every file matches the new HAL.
3. Remove the test line from boot.ini, and the extra halmps.dll/ntkrnlmp.exe copies from system32.

Summary

To take a uniprocessor Windows 2000 SP4 install to multiprocessor on this board: MPS 1.4 disabled in the BIOS, then the MP kernel32/ntdll/win32k from SP4, then the HAL switch, then reapply SP4. The boot.ini test entry makes each step safe to try.

A dual-boot warning: installing the Recovery Console (winnt32 /cmdcons) made the Windows partition the active one, which disabled OS/2’s Boot Manager. If you dual-boot with OS/2, expect to set Boot Manager startable again in LVM afterwards. See Dual-booting OS/2 Warp Server for e-Business and Windows 2000 with LVM and Boot Manager for how.

OS/2 Warp Server for e-Business (WSeB) shipped in 1999, and its install CD’s IDE driver doesn’t get along with the VIA VT82C686B southbridge. On my Asus CUV4X-D (dual Pentium III, VIA 694X + 686B), the stock CD either failed to see the disk or ended in TRAPs and LVM errors. This is what it took to get WSeB installed and running from an SSD at UDMA 5.

The hardware

• Asus CUV4X-D, BIOS 1016, two Pentium III CPUs
• Boot disk: a 60GB SATA SSD on an Ableconn IDE40-SAT (Marvell 88SA8052) SATA-to-IDE bridge, on the onboard IDE with an 80-wire cable
• Install media: the WSeB Server Pak install CD plus CD1

Step 1: put the Dani drivers on the install CD’s boot image

The fix for the IDE problem is Daniela Engert’s replacement drivers: DaniS506 (I used 1.8.15) in place of IBM1S506.ADD, and DaniATAPI (0.4.0) for the CD-ROM. DaniS506 1.8.x only works with DaniATAPI, not IBM’s ATAPI filter, so you need both.

The install CD boots from an El Torito image, a 2.88MB floppy image (DISK_0_1.IMG, also visible as BOOTIMGS/DISK_0_1.IMG on the CD). I did this on a FreeBSD box, but any Unix will do:

1. Copy the boot image out of the ISO and mount it as FAT.
2. Copy DANIS506.ADD onto it.
3. Replace IBMIDECD.FLT with DaniATAPI.FLT, keeping the name IBMIDECD.FLT. The DaniATAPI docs recommend using an IBM name on install disks.
4. Edit its CONFIG.SYS (see the lines below).
5. Write the modified image back over the original in a copy of the ISO, in place and at the same size (e.g. dd conv=notrunc at the image’s offset), so nothing else in the ISO moves.

The CONFIG.SYS changes in the boot image:

REM BASEDEV=IBM1S506.ADD
BASEDEV=DANIS506.ADD /W
REM BASEDEV=IBMATAPI.FLT
PAUSEONERROR=YES

/W makes DaniS506 show its detection results and wait for a key, which is invaluable the first time. It needs PAUSEONERROR=YES. Leave OS2DASD.DMD and OS2LVM.DMD alone. Don’t use DaniDASD: it’s for non-LVM systems, and WSeB uses LVM.

Step 2: also patch the second floppy image

This one caught me out. Once the CD has booted, the virtual A: drive switches to a different image, DISK_2.IMG, so the Dani files you put on DISK_0_1 can’t be reached from the installer’s command prompt. You’ll need them there in step 4, so copy DANIS506.ADD and DANIATAP.FLT onto DISK_2.IMG as well, the same way. I also added a little helper script:

rem FIXDANI - copy Dani IDE/ATAPI drivers onto the installed WSeB volume
if "%1"=="" goto usage
copy A:\DANIS506.ADD %1\OS2\BOOT
copy A:\DANIATAP.FLT %1\OS2\BOOT
echo.
echo Drivers copied to %1\OS2\BOOT. Now edit %1\CONFIG.SYS:
echo   change  BASEDEV=IBM1S506.ADD   to  BASEDEV=DANIS506.ADD /W
echo   put REM in front of the IBMATAPI.FLT and IBMIDECD.FLT lines
echo   add     BASEDEV=DANIATAP.FLT
echo   keep    OS2DASD.DMD and OS2LVM.DMD as they are
pause
tedit %1\CONFIG.SYS
goto end
:usage
echo Usage: FIXDANI C:    (drive letter of the installed WSeB volume)
:end

Step 3: get past the SCSI driver trap (if you have an Adaptec card)

With IDE fixed, my install still trapped after partitioning. The culprit turned out to be IBM’s bundled Adaptec AIC7870.ADD and the AHA-2910C in the machine. I wrote up how I identified it from the trap screen in Which OS/2 driver caused that TRAP? Read the segment limits. For the install, I just removed the card. I haven’t put it back yet. When I do, I’ll try a newer Adaptec OS/2 driver (d10.3.1, from 2002) whose readme lists the AHA-2910C. I haven’t tested it yet.

Step 4: fix the installed system before its first boot from disk

Phase 1 of the install copies drivers from the CD, which means the system it writes to the hard disk has IBM’s IBM1S506.ADD again. Booting it from the disk gave me “OS/2 is unable to operate your hard disk.”

To fix it, boot the modified CD again and press F3 when prompted to get an OS/2 command prompt (WSeB’s own README documents this). Then run:

A:\FIXDANI C:

Make the CONFIG.SYS edits it lists, save, and reboot from the hard disk. After that, WSeB booted from disk and phase 2 of the install ran normally.

Step 5: UDMA 5 instead of UDMA 2

Out of the box, DaniS506 ran the SSD at UDMA 2 (33MB/s). It can’t detect the 80-wire cable on the VIA 686B, so it plays safe. The BIOS saw the drive as UDMA 5 with an 80-wire cable, so the bridge was passing the cable bit and only the driver’s detection was the problem. If you know you have an 80-wire cable, tell it:

BASEDEV=DANIS506.ADD /A:0 /80WIRE

/A:0 applies the option to the primary controller, and I dropped /W at this point. DaniS506 then reported Ultra DMA 5. Don’t do this with a 40-wire cable, since UDMA modes above 2 aren’t reliable on one. As a sanity check, I copied a 500MB test file between volumes and compared it with COMP, and it matched.

Step 6: fixpak

The base install is kernel 14.039. Fixpak XR_E003 applies directly on top of it (you don’t need E001 or E002 first) and takes the kernel to 14.088. Two notes:

• FSERVICE response files may only contain :TAG lines. A leading ; comment gets you CSF0227: Syntax error on line 1.
• Afterwards, check CONFIG.SYS to make sure the DaniS506/DaniATAPI lines survived. Mine did, but it’s worth checking before you reboot.

After the install

• SMP: PSD=OS2APIC.PSD brings up both CPUs.
• BIOS “OS/2 Onboard Memory > 64M”: I tried it both Enabled and Disabled and saw no difference with WSeB on this board.
• Display: I use SciTech SNAP. If you get random screen blanking, see OS/2 screen blanking that comes back on its own? Check APM.
• Dual boot: for adding Windows 2000 alongside WSeB, see Dual-booting OS/2 Warp Server for e-Business and Windows 2000 with LVM and Boot Manager.

An OS/2 TRAP screen looks like a wall of hex, and the line that looks most useful, “internal processing error at location …”, often isn’t. But if the trap happened inside a 16-bit device driver, the register dump usually has enough information to name the guilty driver, without symbols or a debug kernel. The trick is the segment limits.

This is how I tracked down a TRAP 000D while installing Warp Server for e-Business on an Asus CUV4X-D.

The trap

After partitioning, the installer’s boot trapped with this:

TRAP 000d       ERRCD=0000  ERACC=****  ERLIM=********
EAX=00001180  EBX=ffed0000  ECX=00000000  EDX=ffff06d8
ESI=fd7c11e0  EDI=fd7c0000  EBP=0000ff3a  FLG=00213046
CS:EIP=06c8:00005ecc  CSACC=009f  CSLIM=0000eca7
SS:ESP=00e8:0000ff2e  SSACC=0097  SSLIM=0000dfff
DS=06d0  DSACC=00f3  DSLIM=0000b51d  CR0=8001001b
ES=0000  ESACC=****  ESLIM=********  CR2=fbc1b000
FS=0000  FSACC=****  FSLIM=********
GS=0000  GSACC=****  GSLIM=********

The system detected an internal processing error at
location ##0168:fff269a6 - 000e:c9a6.
60000, 9084

0886068a
Internal revision 14.039F_UNI

Step 1: don’t trust the “location” line

The “location” is given as a kernel address, 000e:c9a6. The WSeB CD ships kernel debug maps (OS2IMAGE\DEBUG\UNI\OS2KRNL.MAP on CD1), and the install CD’s kernel matched the retail UNI kernel, so I could look it up:

 000E:0000C9A6       _FormatRegisters

That’s the kernel routine that draws the trap screen. In this case it tells you where the kernel was when it stopped, not where the fault happened. The useful address is CS:EIP in the register dump.

Step 2: CS:EIP is a driver, but which one?

CS:EIP=06c8:00005ecc with CSACC=009f is ring-0 code in a 16-bit selector, which is typical of a .ADD/.SYS driver loaded from CONFIG.SYS. The selector number by itself doesn’t say which driver it is. The limits do.

Old-style OS/2 drivers are 16-bit NE executables. When one is loaded, each of its segments gets its own selector, and the limit is set from the size recorded in the NE segment table: limit = size − 1. For data segments the size is the “minimum allocation”, which can be bigger than what’s stored in the file. So:

• CSLIM=eca7 means the faulting code segment is 0xECA8 bytes.
• DSLIM=b51d means the driver’s data segment is 0xB51E bytes.

Two sizes like that together are effectively a fingerprint. All that’s left is to find the driver on the boot disk with a code segment of exactly 0xECA8 and a data segment of 0xB51E.

Step 3: scan the drivers’ segment tables

Here’s a small Python script that prints each NE segment’s size and the limit it would get:

import struct, sys
for p in sys.argv[1:]:
    d = open(p, 'rb').read()
    ne = struct.unpack_from('<I', d, 0x3c)[0]
    if d[ne:ne+2] != b'NE':
        print(p, 'not NE'); continue
    nseg = struct.unpack_from('<H', d, ne+0x1c)[0]
    segtab = ne + struct.unpack_from('<H', d, ne+0x22)[0]
    print(p)
    for i in range(nseg):
        off, ln, fl, mn = struct.unpack_from('<HHHH', d, segtab + 8*i)
        ln = ln or 0x10000; mn = mn or 0x10000   # 0 means 64K
        kind = 'DATA' if fl & 1 else 'CODE'
        print(f'  seg {i+1}: {kind} filelen={ln:#06x} minalloc={mn:#06x} '
              f'-> limit {max(ln,mn)-1:#06x}')

Run it over every *.ADD, *.SYS, *.FLT and *.DMD on the boot image and look for the limits from the trap screen. For me there was exactly one hit:

AIC7870.ADD
  seg 1: DATA filelen=0x241c minalloc=0xb51e -> limit 0xb51d   <-- DSLIM
  seg 2: CODE filelen=0xeca8 minalloc=0xeca8 -> limit 0xeca7   <-- CSLIM
  seg 3: CODE filelen=0xef62 minalloc=0xef62 -> limit 0xef61

So the trap was in IBM’s bundled Adaptec AIC-7870 SCSI driver (build level 9.23, “d2.11”, dated December 1998). It wasn’t in the IDE driver, LVM or the disk partitioning I had just done, which is where I’d been looking. The machine had an Adaptec AHA-2910C fitted, and the installer loads that driver from its boot CONFIG.SYS.

The fix

For the install, I simply pulled the SCSI card (REMing BASEDEV=AIC7870.ADD in the install image’s CONFIG.SYS would also work).

Caveats

• This works for 16-bit NE drivers, which covers most classic .ADD/.SYS/.FLT/.DMD files. 32-bit LX modules use flat selectors, so the limits won’t identify them.
• Segment sizes aren’t guaranteed to be unique. Matching both CS and DS limits makes a false hit very unlikely.
• Once you know the driver and segment, EIP is the offset into that code segment. If you have a .MAP or .SYM for the driver, you can resolve it to a function.

If your OS/2 machine’s screen periodically goes black, the monitor says “no signal,” and then the picture comes back on its own a few seconds or minutes later, check whether APM is loaded before you start swapping hardware. That was the cause on my Warp Server for e-Business box, and I spent a long time blaming nearly everything else first.

The machine

• Asus CUV4X-D, dual Pentium III (VIA 694X / 686B chipset)
• OS/2 Warp Server for e-Business with fixpak XR_E003, dual-booting Windows 2000 SP4
• NVIDIA GeForce2 GTS (AGP). I also tried two different TNT2 cards.
• SciTech SNAP 3.1.8 for the display driver
• Monitors: a scaler-based Checkmate LCD, and later a Dell 2007FP

The symptom

Some time after OS/2 finished booting, the video signal would drop completely. The Dell’s power LED went amber and the OSD said “no signal.” Sometimes it came back after a few seconds; sometimes it stayed dark for minutes. Moving the mouse or pressing a key did nothing. The system itself was fine the whole time: I could type commands into a window while the screen was black and see the results once the picture returned. Windows 2000 on the same hardware, at the same resolution, never did it.

What it wasn’t

Because the problem was intermittent, several “fixes” looked like they worked for a while and then didn’t. Here’s what I ruled out, in roughly the order I tried it:

• The monitor. I first blamed the Checkmate’s scaler, but the Dell did exactly the same thing.
• The video card. Two TNT2s and the GeForce2 all did it.
• SNAP’s DDC polling. Disabling it seemed to help at first, but it didn’t last.
• SNAP + SMP. SNAP’s documentation says SMP kernels aren’t supported, so this looked very likely. It blanked with OS2APIC.PSD disabled too.
• SNAP itself. It still blanked with the plain VGA driver.
• BIOS power management. It was already completely disabled in setup, including Video Off.
• The network card. One clean run with the cable unplugged looked like a lead, but sustained network copies afterwards couldn’t trigger it.

The fix

Turning off power management in the BIOS doesn’t stop OS/2 from loading its own APM support. My CONFIG.SYS still had all three APM lines. I REM’d them out:

REM DEVICE=C:\OS2\BOOT\APM.SYS
REM DEVICE=C:\OS2\MDOS\VAPM.SYS
REM RUN=C:\OS2\APMDAEMN.EXE

Since then it has run for days, on and off, with the SNAP driver back in place and both CPUs enabled, without a single blank. APM was loaded during every blank I saw and absent from every clean run since.

I’ll be honest that I haven’t done the final proof of putting APM back on its own to see the blanking return. On a desktop machine running as a server, APM does nothing useful for me, so I’m happy leaving it out. I also don’t know the exact mechanism, that is, what the APM daemon is asking the BIOS to do that turns the video off. If you know, I’d love to hear it.

Takeaway

If an OS/2 machine drops video sync and recovers on its own, with no keyboard or mouse input, check CONFIG.SYS for APM.SYS, VAPM.SYS and APMDAEMN.EXE before you replace the monitor, the card or the display driver. It’s a one-reboot test.

In case anyone struggles in figuring out what to do with this card, here’s the deal. On eBay, there are cards labeled as IBM 100/10 Ethernet Adapter, which is a fairly odd, as 100mbit ISA cards aren’t too common. They look like this:

These cards tend to come with part numbers like 25H3511 or maybe 25H3501. I’ve also seen them referred to as IBMFEI cards in some literature. I found a resource online with the mapping of these cards to drivers, which can be found here. Ultimately, for DOS, Win 3.1, Win95, or OS/2 you’ll want to get a hold of ETI1001.EXE (and optionally ETI1002.EXE if you’re using SCO). These are DOS executables which end up writing a floppy image to a 1.44MB diskette, so have one ready.