VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
März 2002
[Inhaltsverzeichnis]
|
| Von Julien Pierre © März 2002, Übersetzung: Robert Henschel |
Gegen Ende 2001 hörte
ich von der allgemeinen Verfügbarkeit zweier Dual-Athlon SMP-Mainboards:
des Tyan Thunder K7 S2462 und des Tyan Tiger MP S2460. Das Tyan Thunder
ist eher ein Mainboard für Server. Es hat einen Onboard-Adaptec-SCSI-Controller
und eine 3COM-Netzwerkkarte. Außerdem benötigt
es ein 460W-Netzteil. Das Tyan Tiger ist mehr auf normale Computernutzer
ausgerichtet. Es besitzt einen PCI-Steckplatz mehr und dafür keine integrierten
SCSI-Controller oder eine Netzwerkkarte. Zusätzlich hatten mich noch positive
Berichte über diese Mainboards von zwei sehr erfahrenen OS/2-Anwendern erreicht.
Daniela Engert hatte eine Maschine mit dem Tyan Thunder zusammengebaut und
Timur Tabi hatte ein System mit dem Tyan Tiger, welches auch ich verwendete.
Ich habe mich für das Tiger MP entschieden. Da dieses Mainboard
Registered DDR-RAM voraussetzt, konnte ich mein 256MB-DIMM aus meinem vorherigen
Athlon-System nicht verwenden. Der Athlon Thunderbird 1.2 GHz ist von AMD
auch nicht für die Verwendung in SMP-Mainboards zertifiziert,
also mußte ich zwei neue CPUs kaufen.Meine Wahl viel auf zwei AMD Athlon MP 1800+ und zwei 512 MB ECC DRR registered DIMMs. Zusätzlich bestand mein System noch aus einem Tekram DC390 U3W 64-bit PCI-SCSI-Controller in einem 64-bit Steckplatz, einer Matrox G450 32 MB DDR AGP Grafikkarte, 3COM 905-Netzwerkkarte und ein Sound Blaster Live Value PCI.
Die Festplatte ist eine neue Seagate Cheetah x15 36.7 GB mit 15.000 rpm.
Als Gehäuse verwende ich ein Lian-Li PC-60, mit PC Power & Cooling Silencer 400W ATX Netzteil.
Ich habe mit dem System einen Monat lang experimentiert. Ich konnte zwar Warp Server for e-business mit SMP Unterstützung installieren, aber es lief nicht stabil. Es kam häufig zu unerklärlichen Systemstillständen, bei denen man nicht einmal mehr die Maus bewegen konnte.
Ich habe die SMP-Unterstützung deinstalliert und trotzdem hängte sich das System auf.
Ich habe sogar einen Einprozessor-Kernel aus Warp 4 ohne SMP installiert, aber die Hänger blieben.
Ich habe mir ein Utility namens BURNK7 besorgt; es testet AMD-CPUs unter Volllast. Die Hänger ließen sich ohne Probleme reproduzieren, mit SMP in einer Minute und ohne SMP in wenigen Stunden.
Unter Windows 2000 lief alles ohne Probleme, auch mit SMP-Unterstützung.
Ich habe alle Teile (CPUs, Speicher, PCI-Karten, Netzteil) in anderen Systemen getestet. Sie liefen ohne Probleme. Also hab ich am Ende entschieden, daß das Mainboard mit OS/2 nicht kompatibel ist, und habe es am 29. von 30 Tagen Rückgabegarantie mitsamt dem Speicher und den CPUs wieder zurückgeschickt. Die restlichen Teile habe ich behalten, das neue Gehäuse, das Netzteil und die Festplatte. Ich habe mein altes Einprozessor Athlon Motherboard, MSI MS-6380, eingebaut.
Ich hatte mir das in etwa so gedacht:
Austausch einer einzelnen Komponente - das MSI Mainboard gegen das Asus A7M266-D - unter Beibehaltung des einen Athlon Thunderbird 1.2 GHz, des DDR-Speichers sowie aller Controller und Festplatten. Wenn es gut läuft, kaufe ich noch zwei neue Athlon MP und installiere die SMP-Unterstützung von OS/2.Als ich nach Hause kam, habe ich das Mainboard getauscht. Es gab keine Probleme beim Anschluß der Controller, des Netzteiles, der CPU und des Speichers.
Es blieb nur folgende Sache:
Mein Tekram DC390 U3W SCSI-Controller ist ein 64-bit/66 MHz PCI-Controller. Ich hatte ihn bis jetzt in einem 32-bit/33 MHz PCI-Steckplatz, da das alles war, was mein altes MSI Mainboard hatte. Da das neue A7M266-D zwei 64-bit/66 MHz PCI-Stecklplätze hat, hoffte ich natürlich, diese benutzen zu können.Unglücklicherweise stellte sich heraus, das sich der Tekram Controller nicht in diese 64-bit Steckplätze einbauen läst. In dem 32-bit Teil des PCI-Steckplatzes auf dem Mainboard war noch eine zusätzliche Kerbe. Wie sich herausstellte, unterscheidet diese Kerbe einen 3.3 Volt PCI-Steckplatz von einem 5 Volt Steckplatz und Tekram unterstützt nur 5 Volt Steckplätze. Deshalb mußte ich meinen SCSI-Controller in einen der 32-bit/33 MHz Steckplätze einbauen. Außerdem konnte ich natürlich keine der anderen meiner 5 Volt 32-bit PCI-Karten in die 64-bit 3.3 Volt Steckplätze einbauen. Also mußte ich alle drei 32-bit PCI-Steckplätze belegen.
Was man noch über das A7M266-D Mainboard wissen sollte, ist folgendes: Es hat keine USB Anschlüsse onboard. Dieser Umstand lässt sich auf einen Fehler im AMD-Chipsatz zurückführen, welcher erst sehr spät in der Entwicklung gefunden wurde. Die USB-Anschlüsse wurden entfernt und eine 32-bit PCI USB 2.0-Karte liegt dem Mainboard bei. Darauf befinden sich ein OHCI-Controller und 4 USB 2.0-Anschlüsse. Glücklicherweise handelt es sich dabei um eine Dual-Voltage PCI-Karte. Das bedeutet, daß man sie sowohl in die 64-bit/66 MHz 3.3 Volt als auch in die 32-bit/33 MHz 5 Volt Steckplätze einbauen kann. Ich habe einen der 64-bit Steckplätze genommen, da das die einzigen sind, die noch frei waren.
Dann habe ich das System angeschaltet. Es lief nicht hoch - die Signaltöne zeigten laut Handbuch ein Fehlen der Grafikkarte an. Ich überprüfte die Karte und natürlich war sie nicht richtig eingesetzt. Ich glaube, sie ist rausgerutscht, als ich den Monitor angeschlossen habe. Dannach bootete das System.
Ich mußte einige BIOS-Einstellungen wie die AGP aperture size ändern, damit OS/2 bis in die WPS booten konnte. Außerdem muß PNP OS auf disabled gesetzt werden,damit alle PCI Karten vom BIOS ordentlich initialisiert werden, so daß OS/2 sie finden kann.
Unter OS/2 mußte ich die IBM USB UHCI-Treiber entfernen, da sie ohne
UHCI-Controller auf dem Asus Mainboard Probleme machten.
Das A7M266-D hat Onboard-Audio mit einem C-Media 8738 Chip. Es gibt einen OpenSource-Treiber von Rüdiger Ihle für diesen Audio-Chip und er läuft problemlos. Mein einziges Problem mit dem Onboard-Sound ist das Fehlen eines digitalen SPDIF-Ausgangs. Weiter gibt es keinen Joystick/MIDI-Ausgang und somit auch keine Möglichkeit, MIDI zum Laufen zu bekommen. Aus diesen Gründen benutze ich auch weiter meine SB Live Soundkarte und blockiere einen PCI-Steckplatz.
Ich habe einige Tests mit dem System gemacht und es lief stabil. Außerdem habe ich BURNK7 über Nacht laufen lassen, und es gab damit kein Problem.
Ich baute alles schnell ein und begann, die OS/2 SMP-Unterstützung
über Installieren/Entfernen zu installieren. Ich hatte nicht viel
Glück nach dem Neustart - das System hing beim Hochfahren der WPS.
Nach dem Entfernen von OS2APIC.PSD aus der CONFIG.SYS bootet OS/2, im Einprozessorbetrieb
natürlich.
Nach vielem Probieren und einem Rat eines freundlichen OS/2-Anwenders
entfernte ich die APM-Treiber aus der CONFIG.SYS und fügte OS2APIC.PSD
wieder ein. Diesmal bootete OS/2, und das System läuft seitdem stabil.
Ich wiederholte den BURNK7 Test mit zwei Kopien - eine für jede CPU
- und er lief die Nacht durch.
USBRESMSG.SYS ist ein Treiber zur Überwachung von USB-Geräten von Markus Montkowski. Ich habe auch andere USB-Geräte angeschlossen, eine Digitale Kamera und ein Smart Card-Lesegerät, und die jeweiligen Namen werden angezeigt. Das zeigt, daß die USB-Anschlüsse funktionieren.REM die nächste Zeile unterstützt die ersten beiden USB Anschlüsse
BASEDEV=USBOHCD.SYS /V
REM die nächste Zeile unterstütz die anderen zwei Anschlüsse
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 wünschte, die PCI-USB2 Karte hätte USB-Steckpfosten anstelle
von USB-Anschlüssen auf der Rückseite. Mein Lian-li PC-60 Gehäuse
hat vier USB-Anschlüsse an der Vorderseite, welche ich gern statt der
Anschlüsse auf der Rückseite benutzen würde. Ich kann natürlich
die Asus PCI-USB2 Karte in der Zukunft durch eine andere ersetzen. Vielleicht
gleich eine Karte mit USB2- und FireWire-Anschlüssen.
Hier ist ein Bild der zwei SCSI Karten. Oben sieht man meinen alten SCSI-Controller, einen Tekram DC390 U3W mit einem LSI 53C 1010 Chip. Wie man an der Länge der Kontakte sehen kann, ist es eine 64-bit PCI-Karte, trotzdem paßt sie nicht in den 64-bit Steckplatz des Asus A7M266-D, sondern nur in einen der 32-bit Steckplätze. An der Anordnung der Kerben kann man erkennen, daß es sich um eine 5 Volt PCI-Karte handelt.
Der SCSI Controller unten ist ein LSI21040 aus der Fedex-Kiste,
die vor meiner Tür stand, als ich heute nach Hause kam, und der sich jetzt
in meinem Computer befindet.
Die LSI21040-Karte hat den selben LSI53C1010 SCSI-Chipsatz wie der Tekram-Controller. Die größten Unterschiede sind das Fehlen von Jumpern und die andere Anordnung der Kerben in den PCI-Kontakten. Ich weiß, es ist wegen der Reflexionen schlecht zu erkennen, aber man kann erkennen, daß die LSI-Karte drei Kerben hat. (Eine befindet sich genau in dem Lichtpunkt so daß man nur noch den oberen Rand sehen kann.) Im Grunde hat die Karte diegleichen zwei Kerben in der Mitte wie der Tekram-Controller plus eine Extrakerbe auf der linken Seite. Durch diese Extrakerbe läßt sie sich in einen 64-bit Steckplatz des Asus Mainboards einbauen.
Als ich den neuen LSI21040 Controller bekam habe ich den alten Tekram DC390
U3W-Controller aus dem 32-bit PCI-Steckplatz 3 ausgebaut, den LSU21040
in den 64-bit PCI Steckplatz eingebaut und alle meine SCSI-Geräte angeschlossen.
Ich bemerkte, daß das SCSI-BIOS mit Version 4.16.00 ziemlich alt war. Meine
Seagate Cheetah X15 wurde mit 80.0 MB/s erkannt. Eigentlich hätten
es 160.0 MB/s sein müssen. Und zusätzlich weigerte sich das SCSI-BIOS,
von dieser Festplatte zu booten. Es beschwerte sich über einen
Festplattenfehler. Sogar als ich von einer DOS Diskette gebootet habe, weigerte
sich FDISK wegen eines Plattenfehlers zu starten.
Ich dachte sofort an eine Aktualisierug des BIOS. Ich hatte bereits meinen alten
Tekram Controller auf die neueste Version 4.19.00 upgedated.
Ich habe also das neue BIOS noch einmal auf einem anderen Computer aus dem Netz heruntergeladen und auf eine DOS-Diskette kopiert. Ich versuchte, das BIOS zu flashen, aber ohne jeden Erfolg. Das LSI Flash Tool fand zwar einen SCSI-Controller, aber kein Flash ROM. Somit konnte das Tool das BIOS nicht updaten. Ich bekam schon Angst, daß es sich um ein gelötetes, nicht flashbares EPROM handeln könnte.
Mir kam die Idee, daß es aber auch ein Fehler im LSI SCSI-BIOS-Flash-Tool
sein könnte. Ich baute den Controller aus dem 64-bit PCI-Steckplatz
aus und in einen 32-bit PCI-Steckplatz wieder ein. Das ist glücklicherweise
möglich, da es sich um eine Dual-Voltage Karte handelt- die sowohl bei
3.3 als auch bei 5 Volt arbeitet, in einem 32-bit/33 MHz oder einem 64-bit/66 MHz
Steckplatz.
Ich bootete den Computer wieder mit der DOS-Diskette und startete
das LSI Logic SCSI-Flash-BIOS-Tool. Es stellte sich heraus, daß ich richtig
gelegen hatte. Dieses Mal fand das Tool den richtigen SCSI-Controller und
auch ein Flash BIOS. Ich konnte die neue Version 4.19.00 erfolgreich einspielen.
Beim nächsten Neustart wurde die Festplatte korrekt mit 160
MB/s erkannt und OS/2 bootete. Das war schon ein Fortschritt, aber noch nicht
ganz das, was ich wollte. Bis jetzt hatte ich wieder einen 64-bit SCSI Controller
in einem 32-bit PCI Steckplatz.
Also führte ich einen Systemabschluß durch und steckt die LSI21040 Karte wieder in einen 64-bit PCI-Steckplatz. Diesmal blieb OS/2 beim Booten hängen. Ich tippte sofort auf einen Konflikt mit anderen PCI-Steckkarten. Ich mußte also meine Karten etwas tauschen, damit OS/2 wieder korrekt bootet.
Hier sieht man die beiden lauffähigen Anordnungen für die
Karten:
Das ist die korrekte Anordnung wie ich sie jetzt habe. Endlich mit einem 64-bit SCSI-Controller in einem 64-bit Steckplatz:64-bit 66 MHz 3.3V PCI slot 1 : Asus PCI-USB2 in
64-bit 66 MHz 3.3V PCI slot 2 : leer
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
Diese Anordnung führte zu einem Konflikt und verhinderte, daß OS/2 korrekt bootet:64-bit 66 MHz 3.3V PCI slot 1 : LSI21040
64-bit 66 MHz 3.3V PCI slot 2 : leer
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
Der LSI21040 Controller verhält sich beim der IRQ-Belegung etwas anders als der Tekram DC390 U3W. Der Tekram hat einen Jumper zum Ändern des PCI-Interrupts für den zweiten SCSI-Kanal, entweder INTA oder INTB. Ich hatte den Jumper auf INTA gestellt, der gleiche wie der erste SCSI-Kanal. Damit belegten beide Kanäle den selben IRQ. Beim LSI21040 ist der erste Kanal fest auf INTA und der zweite fest auf INTB eingestellt. Damit bekommt jeder Kanal einen eigenen IRQ. Unter Umständen kann das zu einem Problem führen, daß hängt aber von den anderen Geräten und deren OS/2-Treibern ab.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 : leer
32-bit 33 MHz 5V PCI slot 4 : 3 Com 905
32-bit 33 MHz 5V PCI slot 5 : SB Live value
Ich sollte noch erwähnen, daß im BIOS steht, daß der Asus
PCI-USB2 Controller drei IRQs belegt (gekennzeichnet als "Serial bus controller").
Ich lade nur zwei Kopien von USBOHCI.SYS und bekomme damit bereits Zugang
zu allen 4 Anschlüssen im USB 1.1 Modus. Vielleicht ist der dritte IRQ
für USB 2.0? Davon abgesehen teilen sich viele PCI-Geräte bei
mir IRQs. Hier ein Auszug von RMVIEW /IRQ:
Es ist mir nicht gelungen die SB Live- und C-Media-Treiber zugleich im MMPM/2 zum Laufen zu bekommen, obwohl es keinen Hardwarekonflikt gibt. Das ist ein Software-Treiber-Problem. Beide Treiber sind aus demselben Kern entstanden und keiner von beiden funktioniert, wenn zwei Treiber geladen werden. Deshalb benutze ich jetzt nur die SB Live im MMPM/2. Ich habe den C-Media-Treiber in der CONFIG.SYS belassen, damit RMVIEW den Gerätenamen anzeigen kann, aber in der MMPM2.INI wird nur der SB Live benutzt.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
Interessanter Weise wird der Symbios SCSI-Controller von
RMVIEW an einem "32-bit bus" angezeigt.
Das ist ein Fehler in RMVIEW. RMVIEW kennt einfach keinen 64-bit PCI-Bus. Die Benchmarks zeigen aber, daß der 64-bit Bus Geschwindigkeitsverbesserungen bringt. Die Zahlen unten stammen von der Tekram-Karte in einem 32-bit Steckplatz. Ich habe auch die LSI21040 Karte in dem selben Steckplatz überprüft und fast die selben Zahlen erhalten. Das ist nicht weiter verwunderlich, da dergleiche Chipsatz und dieselben Treiber verwendet werden.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
Diese Zahlen stammen von der LSI21040 Karte in einem 64-bit / 66 MHz PCI Steckplatz. (wieder mit dem selben SCSIChipsatz und SYM_HI-Treibern)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
Wie man sieht, gibt es keine großen Unterschiede. Der "Cache/Bus transfer"-Test profitiert am meisten, was auch zu erwarten war, da sich die Platte ja nicht schneller dreht. Mehrere Festplatten würden profitieren. Wenn meine 36 GB 15000 rpm Platte voll ist, kann ich mir ja vielleicht eine mit 1 TB und 20000 rpm kaufen, wenn diese hergestellt wird. :-)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, Fall abgeschlossen. Bis zum nächsten Hardware-Upgrade!
Quellenverzeichnis:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org
