VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
March 2002
[Newsletter Index]
|
| 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.
I 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.
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.
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.
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.REM the following line gets the first OHCI with 2 USB ports working
BASEDEV=USBOHCD.SYS /V
REM the following line gets the second OHCI with the other 2 USB ports working
BASEDEV=USBOHCD.SYS /V
BASEDEV=USBD.SYS /REQ:USBOHCD$
BASEDEV=USBHID.SYS
DEVICE=D:\UTILS\USB\USBRESMG.SYS
DEVICE=D:\OS2\BOOT\USBMOUSE.SYS
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.
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 :
Here is the working card arrangement that I now have, finally with a 64-bit SCSI controller64-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
The card arrangement below generated a conflict and prevented OS/2 from booting :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
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.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
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 :
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 .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
Interestingly, the Symbios SCSI controller is listed by RMVIEW as being on a
"32-bit bus".
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 :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
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 : 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
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 :-).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
OK, case closed. My PC case that is. Until the next hardware modification !
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org
