Virtual OS/2 International Consumer Education
VOICE Home Page:
March 2002

[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]

OS/2 SMP on a dual Athlon PC

By Julien Pierre © March 2002

In late 2001, I learned about the availability to the general public of two dual Athlon SMP motherboards : the Tyan Thunder K7 S2462, and Tyan Tiger MP S2460. The Thunder was a server-oriented motherboard, with built-in Adaptec SCSI and 3 Com network, requiring a 460 W power supply. The Tiger was a more general-purpose motherboard which had one more slot, but none of these built-in add-ons. In addition, I had reports from two very experienced OS/2 users of success with these boards - Daniel Engert had setup a machine with the Tyan Thunder, and Timur Tabi had a system with a Tyan Tiger, that I played with.

Tyan Tiger MP S2460

Tyan Tiger MP S2460I decided to go with the Tiger MP. The board required Registered DDR RAM, so I could not reuse the 256 MB DIMM in my existing Athlon system. The Athlon Thunderbird 1.2 GHz CPU I was running also was not certified by AMD to run in SMP mode, so I had to get a brand new pair of CPUs.

I decided to go for a pair of Athlon MP 1800+ CPUs and two 512 MB ECC DDR registered DIMMs. The system was also running with a Tekram DC390 U3W 64-bit PCI SCSI controller in a 64-bit slot, a Matrox G450 32 MB DDR AGP video board, a 3 Com 905 NIC, and a Sound Blaster Live value PCI audio card.

The hard drive was a new Seagate Cheetah x15 36.7 GB 15,000 rpm drive.

The case was a Lian-Li PC-60, with a PC Power & Cooling Silencer 400W ATX power supply.

I experimented with the machine for a month. While I was able to install Warp Server for E-business in SMP mode, it would not run reliably. I was experimenting very frequent and inexplainable system hangs, at which point not even the mouse pointer could be moved.

I uninstalled the SMP module and still got the hangs.

I even installed a plain uniprocessor kernel Warp 4 without any SMP, and the hangs did not go away.

I also got a hold of a utility called "BURNK7" to stress-test AMD CPUs, and it would reproduce the system hang within about a minute when running in SMP mode, and a few hours when not in SMP mode.

I should point out that it worked fine with Windows 2000, even in SMP mode.

I tested all the parts I had (CPUs, memory, PCI cards, power supply) in some of my other systems. They were all  solid. So, I concluded that the motherboard was just incompatible with OS/2, and on the 29th day of my 30-day money back guarantee, I sent it back, along with the CPUs and memory, which I had bought from the same vendor. I kept the rest of the parts, notably the new case, power supply and disk, and ran them in my older  uniprocessor Athlon MSI MS-6380 motherboard.

Asus A7M266-D

In December 2001, I learned that Asus was releasing a new dual athlon motherboard, the A7M266-D. It would feature the new AMD 760 MPX chipset, and would have 64-bit 66 MHz PCI slots instead of the 64-bit 33 MHz of the older Tyan motherboards.  More importantly, I thought it might have a better chance of working reliably with OS/2. And it would also work with non-Registered DDR RAM, which means I could test it without having to buy new RAM.

On January 10, 2002, I was able to find the A7M266-D motherboard locally in Fremont, California at Atacom computers.

My idea for this new experiment was the following :

Swap a single component - replacing the MSI motherboard with the new  Asus A7M266-D - reusing the single Athlon Thunderbird 1.2 GHw CPU and DDR  memory, as well as all controller boards and disks, and see how the  system would work. Then if good, buy a pair of new Athlon MP CPUs and install the SMP component of OS/2.
When I came home, I swapped out the old motherboard and put the new A7M266-D. I had no trouble connecting all the power supply connectors,  installing the CPU or the RAM.

I did however have the following issue :

My Tekram DC390 U3W SCSI controller is a 64-bit/66 MHz PCI controller. I was previously running it in a 32-bit/33 MHz PCI slot since that's old my old MSI motherboard had. The new A7M266-D however has two 64-bit/66 MHz PCI slot, so I was really hoping to take advantage of that.
Unfortunately, I found that the Tekram card could not be inserted into the 64-bit PCI slots. In the 32-bit part of the PCI slot on the motherboard, there was an additional notch. I found out that the reason was that the slot is a 3.3V PCI slot, and the Tekram only supports 5V PCI. Because of this, I was forced to put my SCSI controller in one of the 5V 32-bit / 33 MHz PCI slots. Because of that voltage issue, none of my other 5V 32-bit PCI cards could be inserted in the 64-bit 3.3V PCI slots. Therefore, I filled all three 32-bit PCI slots.

One thing to note about this new A7M266-D motherboard is that it doesn't come with USB onboard. This was due to a bug in the AMD chipset found very late in development, so the USB controller and ports were removed from the motherboard. Instead, it came bundled with a 32-bit PCI USB 2.0 card with two OHCI controllers and four USB 2.0 ports on the back. Fortunately, it was a dual-voltage PCI card, which means it could be inserted into any PCI slot of the motherboard, either 64-bit/66 MHz 3.3 volt slots, or 32-bit/33 MHz 5 volt slots. I chose one of the 64-bit slots as that's all I had free.

I then powered up the system. At first the system didn't come up - the beep codes indicated missing video card according to the manual. I checked it and sure enough, the AGP card wasn't fully inserted - I think it moved when I plugged in the monitor. So I fixed that, and the system came up.

I had to change a few BIOS settings like the AGP aperture to allow the OS/2 GUI to come up, otherwise it would hang when starting the WPS. Most importantly, I had to set the PNP OS setting to "disabled" in order for all the PCI cards to be initialized properly by the BIOS, so that OS/2 could detect them.

On the OS/2 side, I also had to remove the IBM UHCI USB drivers that caused problems in the absence of UHCI USB on the Asus motherboard.

The A7M266-D motherboard has onboard audio with a C-Media 8738 chip. There is an open-source driver by Rüdiger Ihle for this audio chipset, and it works fine. My main grief with the onboard audio is that it doesn't support SPDIF digital output. There is also no joystick/MIDI port on the motherboard so there is no hope of getting MIDI to work. For these reasons, I'm still using an SB Live for the audio, taking up a precious PCI slot.

I did some stress tests with the system, and it has been very solid. I let it run the BURNK7 utility overnight, and it didn't blink.

Running the board in SMP mode

Since I was very satisfied with the stability of the system in uniprocessor mode under OS/2, I then set to buy a pair of Athlon MP CPUs and new RAM. I went to Fry's Electronics in Sunnyvale on Saturday, January 12. The only MP CPUs I could find were Athlon MP 1500+, so I bought them. I also got a pair of Corsair 256 MB DDR ECC Registered DIMMs to replace my single stick of noname non-ECC non-Registered 256 MB DDR memory.

I installed all the chips very quickly, and set to install the OS/2 SMP kernel doing a selective install. I didn't have much luck after the reboot - it just hung when starting the WPS. Commenting OS2APIC.PSD in CONFIG.SYS allowed OS/2 to boot, but in uniprocessor mode only of course.

After much trial-and-error and at the suggestion from fellow OS/2 users, I commented all the APM drivers in the OS/2 CONFIG.SYS and put back OS2APIC.PSD . This time it booted fine, and the system has been rock-solid since. I repeated my BURNK7 tests, this time with two copies - one for each CPUs - and they also ran fine overnight.


I did some benchmarks and you can view the results here.

USB support

One of the things I did not test at first as it was not critical to me was the bundled USB card.  I have found that all four USB ports on the back of the ASUS PCI-USB2 board are working fine with IBM's OHCI drivers. Of course they are working as USB 1.1 for now, since OS/2 does not yet support USB 2.0 speeds. I tested the ports with a USB mouse and it works fine. For others who would want to run this motherboard with OS/2 and USB - the relevant CONFIG.SYS USB drivers setup is :
REM the following line gets the first OHCI with 2 USB ports working
REM the following line gets the second OHCI with the other 2 USB ports working
The USBRESMSG.SYS driver is Markus Montkowski USB monitoring utility, an OS/2 tool that shows USB devices being plugged and unplugged. I tried with a variety of other devices like a digital camera and a smart card reader - none of which have OS/2 drivers, but the device names at least showed up, which further shows that the USB OHCI ports are working with OS/2 on this motherboard.

I wish the PCI-USB2 had USB connectors instead of forcing you to use the USB connectors in the back of the card, which is annoying for connections. My Lian-li PC-60 USB case has four front USB plugs that I would like to use instead. I suppose I could always replace the Asus PCI-USB2  card with another one in the future - perhaps with one that has both USB2 and Firewire ports.

64-bit / 66 MHz PCI SCSI support

As I mentioned above, I could not insert the Tekram DC390 U3W 64-bit PCI SCSI controller into one of the 64-PCI slots on the Asus A7M266-D because of notches and voltage issues.

Please take a look at this image of the SCSI cards. At the top is a picture of my old SCSI controller, a Tekram DC390 U3W, based on an LSI 53C1010 chip. This is the 64-bit PCI card that wouldn't fit in the 64-bit PCI slots of the Asus A7M266-D; it only fit in the 32-bit slots. The Tekram is a 64-bit PCI card as you can see by the length of the connectors. According to the keying of the notches, I can determine that it is a 5V PCI card.

Now, if you look at my picture, the SCSI controller at the bottom is an LSI21040, the one that was in a Fedex box in front of my door when I came home tonight, and that is now in the computer I'm typing this on.

The LSI21040 card has the same LSI53C1010 SCSI chipset as the Tekram controller. The main differences are its lack of jumpers, and the keying of the PCI connector at the bottom. I know it's hard to see because of the reflection in the picture, but you can still see that the connector on the LSI card has three notches (one of them is right in the bright light, you can see the top of it). Basically it has the same two notches as the Tekram controller, plus an extra notch on the left, that allows it to fit in a 64-bit PCI slot on the A7M266-D.

When I got the new LSI21040 board, I took out the Tekram DC390 U3W which was in 32-bit PCI slot 3, and inserted the LSI21040 into 64-bit PCI slot 2, connecting all my SCSI devices. I noticed that the SCSI BIOS was at revision  4.16.00 - a pretty old one. Then, my Seagate Cheetah X15 was recognized only as an 80.0 MB/s device, rather than 160.0 MB/s as it should have been. And to add insult to injury, the SCSI BIOS would not boot from the hard disk at all, complaining about a disk error. Even when I booted from a DOS disk, FDISK wouldn't run, saying there was an error with the fixed disk.

I immediately figured out that I needed to update the LSI SCSI BIOS on the LSI21040 to version 4.19.00 - the latest one, which I had already flashed into the Tekram controller and is the one I was running.

So I downloaded the BIOS again from another system and put in onto the DOS disk, and tried to flash it to the LSI21040. No go ! The LSI flash tool found a SCSI card, but complained it had no flash ROM, and was not able to update it. I was starting to get worried that the SCSI BIOS may be a soldered, non-Flash EPROM.

Then I guessed that the LSI SCSI BIOS Flash utility might not be smart enough to work if the card is in a 64-bit PCI slot. So, I got the idea to move the LSI21040 to a 32-bit PCI slot, which was fortunately possible because the LSI21040 is a dual-voltage PCI card that works all the way from 32-bit 33 MHz to 64-bit 66 MHz PCI, at either 3.3V or 5V.

I then rebooted the DOS disk, and restarted the LSI Logic SCSI flash BIOS utility. My guess was the correct one. This time, the flash tool found the SCSI card and recognized the Flash ROM on it, and the latest 4.19.00 SCSI BIOS version was flashed successfully onto the card !

At the next reboot, the hard disk was recognized correctly as a 160.0 MB/s device, and OS/2 booted successfully ! That was good progress, but not quite what I wanted yet, since I was exactly where I was when I started with the Tekram DC390 U3W - running a 64-bit 66 MHz SCSI controller in a 32-bit 33 MHz PCI slot.

So I shutdown the machine and moved the LSI21040 back into the 64-bit PCI slot 2. Now OS/2 hung during boot. I suspected some PCI slot conflicts. I had to somewhat modify my arrangement of cards to get OS/2 to work.

Here are the two working card arrangements I had :

64-bit 66 MHz 3.3V PCI slot 1 : Asus PCI-USB2 in
64-bit 66 MHz 3.3V PCI slot 2 : empty
32-bit 33 MHz 5V   PCI slot 3 : Tekram DC390 U3W or LSI21040
32-bit 33 MHz 5V   PCI slot 4 : 3 Com 905
32-bit 33 MHz 5V   PCI slot 5 : SB Live value

Here is the working card arrangement that I now have, finally with a 64-bit SCSI controller
running in 64-bit slot :
64-bit 66 MHz 3.3V PCI slot 1 : LSI21040
64-bit 66 MHz 3.3V PCI slot 2 : empty
32-bit 33 MHz 5V   PCI slot 3 : Asus PCI-USB2
32-bit 33 MHz 5V   PCI slot 4 : 3 Com 905
32-bit 33 MHz 5V   PCI slot 5 : SB Live value

The card arrangement below generated a conflict and prevented OS/2 from booting :
64-bit 66 MHz 3.3V PCI slot 1 : Asus PCI-USB2
64-bit 66 MHz 3.3V PCI slot 2 : LSI21040
32-bit 33 MHz 5V   PCI slot 3 : empty
32-bit 33 MHz 5V   PCI slot 4 : 3 Com 905
32-bit 33 MHz 5V   PCI slot 5 : SB Live value

FYI, the LSI21040 is slightly different than the Tekram DC390 U3W in terms of IRQ handling. The Tekram had a jumper to set the PCI interrupt for the second SCSI channel - either INTA or INTB. I had set it to INTA, the same as the first channel. That meant both SCSI channels ended up on the same IRQ. The LSI21040 has the first channel hardwired to INTA and the second channel hardwired to INTB. That means each SCSI channel is on a different IRQ. This can be a problem depending on which other devices are used and how good their OS/2 drivers are at sharing IRQs.

I should mention that the BIOS reports that the Asus PCI-USB2 uses three IRQs (listed as "Serial bus controller"). I'm only loading two copies of USBOHCD.SYS though, and that gives me access to all four USB ports in the back of the card already, in USB1.1 mode. Perhaps the third IRQ is for using the card in USB 2.0 mode ? Regardless, many PCI devices are sharing IRQs. Excerpts from RMVIEW /IRQ output on my box :

RMVIEW: Physical view
  IRQ Level =  0  PCI Pin = NONE  Flg = EXCLUSIVE    TIMER_CH_0
  IRQ Level =  1  PCI Pin = NONE  Flg = EXCLUSIVE    KBD_0 Keyboard Controller
  IRQ Level =  2  PCI Pin = NONE  Flg = EXCLUSIVE    PIC_1
  IRQ Level =  3  PCI Pin = NONE  Flg = MULTIPLEXED  SERIAL_1 Serial Controller
  IRQ Level =  4  PCI Pin = NONE  Flg = MULTIPLEXED  SERIAL_0 Serial Controller
  IRQ Level =  6  PCI Pin = NONE  Flg = MULTIPLEXED  FLOPPY_0 Floppy Controller
  IRQ Level =  7  PCI Pin = NONE  Flg = MULTIPLEXED  PARALLEL_0 Parallel Port Adapter
  IRQ Level =  8  PCI Pin = NONE  Flg = EXCLUSIVE    RTC
  IRQ Level = 10  PCI Pin = A     Flg = SHARED       OHCI Compliant USB Host Controller
  IRQ Level = 10  PCI Pin = A     Flg = SHARED       LSI Logic SYM_HI   Controller
  IRQ Level = 10  PCI Pin = A     Flg = SHARED       C-Media 8738 Codec
  IRQ Level = 11  PCI Pin = A     Flg = SHARED       LSI Logic SYM_HI   Controller
  IRQ Level = 14  PCI Pin = NONE  Flg = SHARED       Creative Labs SoundBlaster Live!
  IRQ Level = 15  PCI Pin = B     Flg = SHARED       OHCI Compliant USB Host Controller

I couldn't get both the SB Live and C-Media drivers to work in MMPM/2 at the same time, even though there is no hardware conflict between them. This is a software driver issue - both drivers are built from the same core and neither of them works if the two drivers are installed. So right now I'm just using the SB Live in MMPM/2. I left the C-Media driver loaded in CONFIG.SYS just so RMVIEW would show the device name, but it is not referenced in MMPM2.INI .

Interestingly, the Symbios SCSI controller is listed by RMVIEW as being on a "32-bit bus".

      Adapter: LSI Logic SYM_HI   Controller

      Device Type: MS-SCSI        Bus/Width: PCI 32 BIT

      IRQ Level = 11  PCI Pin = A     Flg = SHARED      

      Memory Base = 0XBA000000  Size = 00000100  Flg =  EXCLUSIVE  

        Device: DISK_0      SEAGATE  ST336752LC       0002   FIXED  DISK        

      Adapter: LSI Logic SYM_HI   Controller

      Device Type: MS-SCSI        Bus/Width: PCI 32 BIT

      IRQ Level = 10  PCI Pin = A     Flg = SHARED      

      Memory Base = 0XB9000000  Size = 00000100  Flg =  EXCLUSIVE  

        Device: CDROM_1      YAMAHA   CRW2200S         1.0D   REMOVABLE  CDROM       

        Device: DISK_2      MicTec   DPAI-SCSI        c2.7   REMOVABLE  DISK        

        Device: DISK_3      MicTec   DPAI-SCSI        c2.7   REMOVABLE  DISK        

        Device: CDROM_4      TOSHIBA  DVD-ROM SD-M1401 1009   REMOVABLE  CDROM       

That's a bug in RMVIEW. It is simply unaware that 64-bit PCI buses exist. Nevertheless, the benchmarks show that the 64-bit bus improves performance. The numbers below are with the Tekram card in a 32-bit slot. I also tested with the LSI21040 card in the same slot and got nearly identical numbers - which is not surprising since the same chipset and SYM_HI drivers are used :
 Disk I/O disk 0-1: 35001 MB - SEAGATE ST336752LC 0002
   Avg. data access time :        6.000    milliseconds
   Cache/Bus xfer rate   :       62.557    Megabytes/second
   Track 0 xfer rate fwd :       57.680    Megabytes/second
   Middle trk rate fwds. :       53.845    Megabytes/second
   Last track rate bwds. :       35.940    Megabytes/second
   Average Transfer rate :       49.155    Megabytes/second
   Disk use CPU load     :        4.950    percent
   Total                 :      283.621    Disk I/O-marks

The numbers below are with the LSI21040 card (again same SCSI chipset, same SYM_HI drivers) in a 64-bit 66 MHz PCI slot :
 Disk I/O disk 0-1: 35001 MB - SEAGATE ST336752LC 0002
   Avg. data access time :        5.800    milliseconds
   Cache/Bus xfer rate   :      100.040    Megabytes/second
   Track 0 xfer rate fwd :       57.688    Megabytes/second
   Middle trk rate fwds. :       53.821    Megabytes/second
   Last track rate bwds. :       41.366    Megabytes/second
   Average Transfer rate :       50.958    Megabytes/second
   Disk use CPU load     :        4.170    percent
   Total                 :      300.009    Disk I/O-marks
Not a huge difference as you can see, it's the cache/bus transfer test that benefits primarily, but that was expected since the disk won't spin faster. Multiple disks would benefit though, when I fill my 36 GB 15k rpm, I can maybe get a 20k rpm TB drive when they make it :-).

OK, case closed. My PC case that is. Until the next hardware modification !


Julien's site -

[Feature Index]
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: