VOICE Homepage: http://www.os2voice.org

[Newsletter Inhalt] [Vorherige Seite] [Nächste Seite] [Artikelübersicht]

Über die Jahre habe ich sehr viele Leute kennengelernt, die aufgrund Ihres beruflichen Umfelds auch zu Hause ein SCSI-System einsetzen. Sie sind zwar zugegebener Maßen in der Minderheit, dafür schwören Sie aber um so vehementer auf das SCSI-Prinzip.

Wenn ich mit Ihnen aber über SCSI im privaten Einsatz auf dem PC zu Hause spreche, fällt seltsamerweise immer nur ein Name: Adaptec. Das ist zwar löblich und spricht nicht zuletzt auch für die gute Qualität der Treiber (und des Marketings), jedoch sollte man darüber hinaus nicht vergessen, daß es auch hier noch andere Hersteller gibt, die mit interessanten Alternativen aufwarten. Einen dieser Hersteller möchte ich hier heute etwas näher vorstellen - die Firma Dawicontrol; am Beispiel des UltraWide-SCSI3-PCI-Controllers DC-2976UW.
 

Made in Germany

Vor etlichen Jahren habe ich einmal einen netten Gag im Fernsehen gesehen: Auf einer sternbehafteten Luxuslimousine prangte die stolze Banderole "made in germany". Als die Kamera immer näher heranfuhr erkannte man, daß ganz klein darunter stand "printed in taiwan".

Ungeachtet dieser Selbstironie ärgert es mich trotzdem, daß meine Bekannten mich immer erstaunt anschauen, wenn ich sage, daß Dawicontrol ein deutscher Hersteller von SCSI-Controllern ist. Unter dem Begriff "deutsche Hardware" stell sich der IT-Professional heutzutage scheinbar nur noch Autos, Panzer, Waschmaschinen oder klobige und überteuerte PC-Komponenten vor... Dawicontrol beweist jedoch in jeder Hinsicht, daß es auch anders geht.
 

Zufall

Eigentlich ist es einem plötzlich ausgefallenen Adaptec AHA-2940 zu verdanken, daß ich vor ein paar Jahren auf die Produkte aus Göttingen aufmerksam wurde. Damals stieß ich auf den unglaublich günstigen DC-2974, einen preiswerten PCI-SCSI-Controller, der im Leistungsumfang ziemlich genau dem defekten Adaptec-Modell entsprach.

Als OS/2-Anwender stehe ich immer ein wenig skeptisch solchen Sachen gegenüber - nicht zuletzt auch wegen der Treiberunterstützung bei neuen Produkten. Aber siehe da - laut Homepage gab es für alle Produkte auch OS/2-Treiber. Ich entschloß mich dazu, das "Risiko" einzugehen. Und ich wurde nicht enttäuscht: Nach Einbau, Verkabelung und Treibereintragung in der CONFIG.SYS lief das System genau so wie vorher (es hätte auch anders kommen können...).

Mittlerweile sind ein paar Jahre ins Land gegangen und mein Server läuft mit einem DC-2975U, die "kleine" Workstation meiner Frau lief bis zu Ihrer Ausschlachtung - pardon: ihrem "Umbau" - mit dem DC-2974 und da kürzlich mein Adaptec AHA-2940UW seinen Dienst versagte (warum gehen die eigentlich einfach plötzlich kaputt?) hielt ich es für eine gute Gelegenheit, das nächste Familienmitglied auch aus dem Göttinger Stall kommen zu lassen.
 

Auf den ersten Blick

Auf dem Karton und der Kurzanleitung prangt das OS/2-Logo. Schön, daß es das noch gibt.
Der umweltbewußte Verbraucher wird es begrüßen, daß bei der Verpackung auf Luftpolsterfolien, Schaumgummimatten oder Styropormaterial verzichtet wurde - sie besteht ausschließlich aus Karton. Einzige Wermutstropfen sind die antistatische Schutzhülle (die muß leider sein!) und die dünne Folie, in die der Karton eingeschweißt wurde - das scheint mir aber auch vertretbar, denn die Vollständigkeit und Unversehrtheit des Inhalts muß nun mal irgendwie gekennzeichnet werden - sei es durch einen fetten, runden Aufkleber an einer beliebigen Lasche oder eben durch eine verschweißte Folie.

Einmal ausgepackt haben wir als Inhalt den Controller, eine gedruckte Kurzanleitung, die Treiberdiskette und die beiden internen Anschlußkabel (50-polig und 68-polig) vor uns liegen.
 
 

Auf den zweiten Blick

Der Chip, der auf dem DC-2976UW zum Einsatz kommt, ist ein SYM53C875 von Symbios, die mittlerweile unter dem Namen "LSI Logic" firmieren. Das ist nicht uninteressant, da sich daraus Möglichkeiten ergeben, die für Installation und Betrieb nützlich sind, wie in den folgenden Abschnitten ersichtlich werden wird. Der Controller verfügt über drei Anschlüsse: Intern jeweils einen 50- und 68-poligen, extern einen 68-poligen High Density (HD)-Anschluß. Da der Controller sich gemäß SCSI-Philosophie in der Mitte der SCSI-Kette befindet, kann man also nur zwei der drei Anschlüsse zusammen betreiben - andernfalls hätte man eine sternförmige Topologie und keinen "Bus" mehr, was zu Problemen führte. Diese Einschränkung ist zwar lästig, in dieser Controllerklasse aber durchaus üblich.

Die mitgelieferten Anschlußkabel haben jeweils drei Abgriffe, d.h. Sie können jeweils zwei Geräte an den 8-Bit-Bus (50-poliges Kabel) und den 16-Bit-Bus (68-poliges Kabel) anschließen, da der dritte Abgriff natürlich für den Anschluß am Controller gedacht ist. Das sollte für die meisten privaten SCSI-Anwender reichen - wer mehr Geräte hat, hat garantiert auch schon entsprechende Kabel. Der DC-2976UW besitzt zwei Jumper für die jeweilige Terminierung des 8-Bit-Bus und des 16-Bit-Bus. Diese Jumper stehen werksseitig auf Automatisch. So erkennt der Controller selber, an welchen seiner Anschlüsse sich Geräte befinden.

Ich möchte hier nicht die Grundlagen der SCSI-Schnittstelle auswälzen, es genügt wohl zu bemerken, daß man die Terminierung auch manuell auf ON bzw. OFF stellen kann. Bei allen meinen bisherigen SCSI-Controllern mit diesem Feature - unabhängig vom Hersteller - hat Automatisch immer funktioniert.

Während ich meinen Akkuschrauber (ALDI) greife und überlege, ob Katze oder Kind für den Verlust des Kreuzschrauben-Bits verantwortlich sind, streift mein Blick kurz das Handbuch. Wieso heißt das Handbuch eigentlich jetzt "Kurzanleitung"? Ein Blick ins Inhaltsverzeichnis reicht, um diese Frage restlos zu beantworten:
Keine Spur von OS/2 (und keine Spur von Linux oder Novell). Nur Windows 95, 98, NT und 2000. Ein weiterer Blick - diesmal auf die erste Seite - klärt die Verhältnisse:

Aha. Trotzdem: Dumm gelaufen, denn eine CD ist nicht im Lieferumfang... und mal angenommen, mein PC läge in Teilen zu meinen Füßen - wie komme ich dann ins Internet?
Okay, okay - die Treiber sind ja auf der Diskette und wir wissen wie es geht, aber für einen OS/2-Neuling (ja, das soll es geben) oder einen SCSI-Neuling fangen jetzt die Probleme an. Das verstehe ich nun wirklich nicht - aufgrund meiner bisherigen Erfahrungen hatte ich Dawicontrol eigentlich immer als das schillernde Beispiel für gute Handbücher in Erinnerung... und nun das.

Naja, ich habe mir das PDF heruntergeladen und es ist wirklich so gut, wie ich es in Erinnerung hatte. Noch besser wäre es aber gewesen, wenn es direkt im Karton gelegen hätte... wie früher... oder eben in Form dieser seltsamerweise fehlenden CD oder von mir aus auch (bei einer Dateigröße von 245K) auf einer separaten Diskette.

Beim Thema Diskette sollte man die unerfahrenen SCSI-Anwender vielleicht darauf hinweisen, daß Treiber auf Disketten auszuliefern kein Zeichen von Rückständigkeit ist - überlegen Sie doch 'mal, wie Sie an die Treiber auf der CD rankommen, wenn Sie noch keinen Treiber für Ihr CD-ROM-Laufwerk geladen haben... na? Natürlich (seufz) gibt es auch Tricks und Kniffe, ohne einen zweiten PC an die Daten auf der CD zu kommen und natürlich es gibt auch Leute ohne Diskettenlaufwerk... aber: Mit Disketten geht's halt am leichtesten. Dabei fällt mir ein: Ob dies vielleicht der Grund für die fehlende CD ist? ;)
 

Hardwareeinbau

Der "Dawi" wandert in den zweiten PCI-Slot, den schon sein Vorgänger bewohnte... und sitzt perfekt. Auch beim Festschrauben zieht sich die hintere Kante nicht wieder aus dem Slot - gut abgemessen. (Das Gehäuse meines Rechners hat sich in dieser Hinsicht als Referenzgerät herausgestellt.)

Über IRQs mache ich mir keine Sorgen: Da ich keine IDE-Geräte in diesem Rechner betreibe, habe ich in seinem BIOS beide IDE-Controller deaktiviert und ihre IRQs freigegeben. Plug and Play kann ich nicht leiden (das ist eine andere, persönliche Geschichte), deshalb vergebe ich die Ressourcen manuell. Der Slot meiner Matrox G200 belegt IRQ14, der Slot des SCSI-Controllers den IRQ15.

Jetzt noch die Kabel anschließen: Da ich an diesem Rechner keinen Scanner betreibe und der externe Anschluß somit frei bleibt, kann ich beide interne Anschlüsse nutzen, wie das schon beim 2940UW von Adaptec der Fall war. Am 16-poligen Anschluß hängt eine IBM-Platte, am 8-poligen Anschluß der Rest: CD, Brenner, Streamer, Zip und eine zweite Platte.

Die Terminierung auf den Strängen sowie die ID-Vergabe war vorher bereits korrekt und da ich daran keine Änderungen vorgenommen habe, geht's nun sofort weiter...
 
 

Erstes Booten

Beim Hochfahren meldet sich der Controller unmittelbar an der Stelle, an der sonst ein Abtasten bzw. Identifizieren der IDE-Geräte erfolgen würde. Neben der BIOS-Version zeigt der Controller auch die belegten Ressourcen an ("meinen" IRQ15, die automatisch gewählte ROM- und I/O-Adresse).
Wie jeder SCSI-Controller mit eigenem BIOS, gibt auch der DC-2976UW eine Meldung aus, wie man in sein BIOS-Setup gelangt. Während Adaptec hier das <STRG-A> bevorzugt und Tekram <F2> oder <F6> verwendet, hat man sich bei Dawicontrol dazu entschlossen, es dem Phoenix/AMI-BIOS gleichzutun und dies über die Taste <ENTF> zu realisieren.

Wenn man nicht ins BIOS-Setup einsteigen will, erfolgt nun nach einem "echten" Power-on (nicht Reset oder Warmstart) eine Wartezeit von 15 Sekunden, die man mit <ESC> abbrechen kann, was einem zu diesem Zeitpunkt auch angezeigt wird. Dies dient dazu, vor allem älteren Geräten eine bestimmte Zeitspanne zur Initialisierung zu geben bevor der Bus-Scan erfolgt, der ansonsten vielleicht problematisch oder unvollständig wäre. (Dieses PowerOn Wait kann im Controller-BIOS eingestellt bzw. deaktiviert werden.)

Der Bus-Scan verwöhnt den Anwender nicht unbedingt mit vielen Informationen. Alle vom BIOS unterstützten Geräte werden angezeigt mit SCSI-ID, Hersteller- und Gerätenamen. Bei Festplatten wird zusätzlich noch ausgegeben, welcher Laufwerksbuchstabe Ihnen zugeteilt wird und mit welcher Kopf- bzw. Sektorenzahl der Controller arbeitet. Das war's.

Nun kann man sich streiten, ob detaillierte Informationen zur Synchronisierung oder der maximalen Transferrate bereits beim Bootvorgang angezeigt werden müssen. Dawicontrol macht es jedenfalls nicht. Ein weiterer Punkt ist die Vergabe des Laufwerksbuchstabens. Hier handelt es sich wohl eher um eine Visualisierung, in welcher Reihenfolge welches Laufwerk erkannt und unterstützt wird. Eine Festplattennummer wäre sicher unverfänglicher, da gerade wir OS/2-Anwender ja genau wissen, was alles mit Laufwerksbuchstaben passieren kann, je nachdem welches Betriebssystem geladen wird.
Hiernach beginnt jedenfalls der Start des Betriebssystems - in meinem Fall erscheint nun der OS/2 Bootmanager... eine gute Gelegenheit, sich einmal detailiert mit einer wichtigen Komponente - dem Controller-BIOS - auseinanderzusetzen.
 
 

Controller-BIOS

Wie bereits erwähnt kann man im BIOS einige Eigenschaften des Controllers beeinflussen. Alle Hardwareressourcen (IRQ, I/O-Adresse, ROM-Adresse) werden automatisch belegt. Hierauf hat man keinen Einfluß, es sei denn, man vergibt dem PCI-Slot manuell einen IRQ im BIOS des Rechners. Zu den einstellbaren Eigenschaften gehört das PowerOn Wait, also die Wartezeit nach einem echten Kaltstart, die man aktivieren oder deaktivieren kann. Die Dauer von 15 Sekunden ist jedoch fest vorgegeben.

Für das boot device - also das Gerät, welches für den Bootvorgang verwendet werden soll - lässt sich die SCSI-ID vorgeben. Voreingestellt ist hier die ID 0, was de facto-Standard ist. Auch die durch den Controller zu belegende SCSI-ID läßt sich einstellen. Hierfür ist auto voreingestellt, was bei mir zur "klassischen" SCSI-ID 7 führt.

Der Controller unterstützt bootfähige CD-ROMs, das habe ich aber nicht testen können, da ich keine solche CD besitze. Das Controller-BIOS kann Wechselmedienlaufwerke als Festplatten betreiben, wenn die zugehörige Option aktiviert ist. Das habe ich aber ebenfalls genauso wenig getestet wie die aktivierbare Unterstützung mehrfacher logischer Einheitennummern (multiple LUN support, z.B. für CD-Wechsler). Soweit zu den einstellbaren Features des Controllers.

Der DC-2976UW unterstützt bis zu 15 Geräte. Inklusive des Controllers können also hier für 16 Geräte folgende Einstellungen gemacht werden (Voreinstellung jeweils unterstrichen):
 

Die Einstellung "Bios Unterstützung = NEIN" führt dazu, daß ein Gerät für Zugriffe über den BIOS-Interrupt 13h unsichtbar bleibt, d.h. das betreffende Gerät wird beim Start eines Betriebssystems nicht unterstützt. Das ändert sich dann mit dem Laden des Adaptertreibers, der zunächst einmal grundsätzlich alles erkennt, was angeschlossen ist - es sei denn, man hat entsprechende Befehlszeilenparameter mitgegeben. Hinsichtlich des Verwendungszwecks dieser Möglichkeit muß ich zugegebenermaßen erst mal nachdenken - ich kann mir aber vorstellen, daß es durchaus Situationen und Konfigurationen gibt, in denen man dem startenden Betriebssystem bestimmte Geräte zunächst vorenthalten möchte.
Disconnect/Reselect ermöglicht es dem betroffenen Gerät, sich während der Verarbeitung eines Befehls vom SCSI-Bus zu "trennen" und sich danach wieder zu verbinden. Dadurch wird erreicht, daß der SCSI-Bus für andere Befehle bzw. Aktionen zur Verfügung steht. Wenn Sie beispielsweise ein Dokument scannen, würde dieser Vorgang Ihren SCSI-Bus blockieren und Sie könnten nichts "anders tun" bis der Scanvorgang abgeschlossen ist. Glücklicherweise ist diese Option standardmäßig für alle Geräte-IDs aktiviert. Unglücklicherweise gibt es aber auch viele Scannermodelle, die das disconnect/reselect-Verfahren nicht unterstützen, womit wir wieder beim Sanduhreffekt wären.

Schade ist, daß auf diesem Schirm nicht die Gerätebezeichnungen sondern lediglich die IDs verwendet werden. Das Scannen (Identifizieren) der am SCSI-Bus angeschlossenen Geräte, das hierfür erforderlich wäre, kann aus dem BIOS-Setup heraus nicht gestartet werden. Innerhalb des Bootvorgangs erfolgt es erst nach dem möglichen Einstieg ins BIOS-Setup.

Dieses Verfahren dient wahrscheinlich dazu, daß man selbst bei einem fehlerbehafteten SCSI-Bus sofort in das Setup gelangt - ohne vorher den dann langwierigen Scan ertragen zu müssen. Ich muß zugeben, daß mir in dieser Hinsicht die Lösung von Adaptec besser gefällt. Hier beginnt das BIOS-Setup mit einem Menü, in dem man zwischen der Einstellung des Controllers oder denen der Geräte wählen kann. Letztere Option führt dann den besagten Scan aus. Diese Variante ist zwar auch nicht gerade die perfekte Lösung, aber schon um einiges angenehmer.

Im Großen und Ganzen ist das BIOS-Setup zwar ausreichend, jedoch etwas spartanisch verglichen mit denen der Mitbewerber, die zum Teil sogar das Prüfen eines Mediums oder die Low-Level-Formatierung der angeschlossenen Festplatten direkt aus dem BIOS-Setup heraus ermöglichen. Diese erweiterten Funktionen stecken bei Dawicontrol in einem DOS-Tool auf der (nicht bootfähigen) Treiberdiskette, welches auch zur Aktualisierung des Flash-BIOS eingesetzt wird. Nun kann man sich aber auch streiten, ob solche Funktionen überhaupt noch zum Umfang eines BIOS-Setups gehören oder nicht eventuell doch irgendwo anders hingehören, wie man es bei Dawicontrol letztendlich gemacht hat.
 

Treiberinstallation - die erste

Ich unterscheide persönlich immer zwischen zwei Varianten dieses netten Spiels: Einerseits der Installation in ein lauffähiges System, wenn Sie also zum Beispiel einen Controller austauschen und andererseits der Installation im Rahmen der Betriebssysteminstallation - auf einem nackten PC sozusagen.

Im ersten Fall (OS/2 ist bereits installiert) würde man es dank der INT13-Unterstützung des Controller-BIOS problemlos schaffen, mit <ALT-F1> und dann <F2> den PC in eine OS/2-Shell zu starten. Okay, die Meldung daß der evtl. vorher verwendete Treiber nicht geladen werden konnte müßte man in Kauf nehmen, ebenso, daß man nicht auf CDs zugreifen kann... was soll's. Es würde allemal reichen, um den DC2976.ADD ins Verzeichnis \OS2\BOOT kopieren zu können, die CONFIG.SYS entsprechend zu ändern und schon wäre man am Ziel... wenn man Glück hat.

Wenn man allerdings Pech hat, sind die zur Formatierung eingesetzten Algorithmen der Controllerhersteller nicht kompatibel. Das äußert sich dann - relativ schnell - in einem Trap. Die Folge davon ist, daß Sie nicht umhinkommen werden, eine Formatierung durchzuführen. Bei der Neuinstallation von OS/2 wird es dann zusätzlich Probleme mit dem Zugriff auf die bereits vorhandene Partition geben... kurz gesagt: Machen Sie sich auf einen langen Abend gefaßt. Wenn Ihnen eine Low-Level-Formatierung aufgrund der Festplattengröße nicht zusagt, sollten Sie zumindest mittels FDISK per Bootdiskette die spätere OS/2-Installationspartition entfernen.

Grundsätzlich können Sie davon ausgehen, daß ein Controller mit Symbios-Chip eine auf der Festplatte vorher eingesetzte Adressierungsgeometrie eines Adaptec-Controllers verwenden kann. Das ist eventuell nützlich, wenn Sie keine (aktuelle) Sicherung des betreffenden Laufwerks haben und dringend auf die dort gespeicherten Daten zugreifen müssen oder wenn es sich um Festplatten im Wechselrahmen handelt, die in unterschiedlichen Systemen zum Einsatz kommen. Generell sollten Sie jedoch dem Controller mittels Low-Level-Formatierung erlauben, seine eigenen Zugriffsverfahren einzusetzen, da diese nativen Methoden verlässlicher und schneller arbeiten als eine eingebaute "Emulation" - mag sie auch noch so gut sein.

Aber bleiben wir auf dem Boden der Tatsachen: Bei mir hat das Verfahren geklappt.
Dennoch - das wäre ja zu einfach. Hier Variante zwei:
 

Treiberinstallation - die zweite

Da ich ohnehin seit längerer Zeit vorhatte, OS/2 einmal komplett neu zu installieren, kam mir diese Gelegenheit günstig - einzige Voraussetzung: Ein lauffähiger PC mit Diskettenlaufwerk.
Das Szenario dürfte ja bekannt sein: Ändern der Diskette 1, um Platz zu schaffen für den Treiber. Wir kopieren also zunächst die Diskette 1, löschen CDINST.EXE und das readme, kopieren den Treiber drauf und passen die CONFIG.SYS an. (Ich bevorzuge hier, alle übrigen Controller-".ADDs" und CD-ROM-".FLTs" mittels REM zu deaktivieren, damit einzig der DC2976.ADD geladen werden soll. Natürlich könnte man auch den Snooper-Kram entfernen, aber das gehört hier nicht unbedingt hin.) Ach so, ja: SET COPYFROMFLOPPY=1... aber Hallo! Bloss nicht vergessen! ;) Die Warp-CD einlegen, Installationsdiskette einlegen, und auf ins Abenteuer... Hm... seltsam... alles funktioniert. Wie unspektakulär.

Hier fällt mir auf, daß beim Laden des Treibers (mit /V-Option) mehr Informationen angezeigt werden als während des Hardware-Bootvorgangs. Neben den Ressourcenangaben (wie beim Hochfahren) erscheint noch die Treiberversion, die gewählte Einstellung der Stromsparfunktionalität (nur über den Treiber aktivierbar, Standard: Inaktiv) und in der Geräteliste eine Angabe, ob das jeweilige Gerät synchron oder asynchron kommuniziert.

Das erste Manko der Treiber zeigt sich aber nach dem textbasierten Teil der Installation, wenn der Rechner neu startet und man im Installationsprogramm angekommen ist: Die Auswahlliste Unterstützung für SCSI-Adapter zeigt an keine. Nun ja - damit das funktioniert, müßten noch ein paar Schritte mehr ablaufen, als es das standardisierte OS/2-Installationsverfahren ermöglicht. Die Datei SCSI.TBL müßte um einen entsprechenden Eintrag erweitert werden und ein "presence checker"-Programm für den Controller (bzw. den Chipsatz darauf) müßte im Lieferumfang enthalten sein. Angesichts des ohnehin erforderlichen manuellen Aufwands zur Erstellung einer entsprechenden "Diskette 1" könnte man hier auch die (optionalen) notwendigen Schritte zur Gewährleistung der automatischen Erkennung dokumentieren. Aber es wäre wohl zu viel verlangt, wenn man die Hersteller dazu auffordert, gefälligst die Unzulänglichkeiten in IBMs Installationsprozeß zu umschiffen - aber lassen wir das. Was ich hierbei nicht verstehe, ist die Tatsache, daß ein Presence-Checker für den Chipsatz bei dessen Hersteller existiert, dieser aber von Dawicontrol nicht übernommen wurde und an den Endkunden ausgeliefert wird. Sei's drum.

Beim Durchtesten, ob ZIP, CD und Streamer funktionieren, gibt es nichts zu klagen - die Performance kann einem Adaptec 2940UW das Wasser reichen und der Controller arbeitet absolut stabil. Was will man mehr? Nun testen wir 'mal die FixPaks durch. Alles ist soweit okay, bis auf..., ja...
 

FP14 (und Kernelfixes)

Womit wir beim zweiten Manko wären: TRAP C beim Laden des Treibers. Das sieht böse aus.

Ich schaue auf der Website von Dawicontrol in die FAQs... nichts. Keine Angaben zu OS/2. Ich schaue nach, wie man den Support anmailen kann... gar nicht. Wie - gar nicht? Nur Telefonnummer? Ich rechne mit dem Schlimmsten. Aber was ist das? Keine 0190... keine 0180-5... eine ganz normale Telefonnummer. Uff.

Ich rufe also an und klage sofort mein Leid. In allen Details. Die nette Dame, die sich alles geduldig anhört, sagt, daß sie mich weiterverbinden muß, da Sie "nur" die Zentrale ist... dann habe ich einen Herrn am Telefon. Jetzt bin ich schon besser und brauche nur noch einen Bruchteil, um das ganze Problem darzustellen. Er sagt, der OS/2-Spezialist des Hauses sei momentan zu Tisch (stimmt: es ist kurz nach Mittag) und er würde ihm das Problem schildern. Ich bereite mich insgeheim darauf vor, nie wieder etwas aus Göttingen zu hören, verabschiede mich mit "okay - dann bis später" und lege auf.

Ein paar Stunden später klingelt das Telefon. Der Herr von Dawicontrol ist wieder dran. Unglaublich. Er sagt, mit dem Aurora-Kernel (WSeB-Kernel), der im FP14 drin wäre, gäbe es einige Probleme. (Tja, wer möchte da wohl widersprechen?) Die Entwicklungsabteilung, die sehr klein sei, könne sich um das Problem momentan nicht kümmern, da alle Ressourcen gebunden wären in der Entwicklung eines U160+-Controllers samt Treiber.
Da ich mich aber mittlerweile schlau gemacht habe, weiß ich, daß der Chip von Symbios (LSI Logic) ist und frage ihn, ob die Treiber von Symbios da vielleicht Abhilfe schaffen. Er meint, das sei eine gute Idee, ich könne die Symbios-Treiber grundsätzlich verwenden und nennt mir den Namen des Chips "zur Sicherheit"... aber er wisse nicht, ob es damit klappen würde.

Was soll ich lange erzählen: Es klappt - mit den Symbios-Treibern funktioniert das Fixpak 14 tadellos.

Jetzt wäre der Artikel eigentlich vorbei - allerdings hat mich die Neugier gepackt: Ich will jetzt wissen, wie gut die Treiber von Symbios sind, und wo die Unterschiede zu denen von Dawicontrol liegen.
 

Triebtäter

Bis zum WSeB-Kernel laufen sowohl Treiber von Symbios als auch die Treiber von Dawicontrol auf dem DC-2976UW. Ich vergleiche die Performance mittels Sysbench (V 0.9.3).

Egal was ich auch messe - die beiden Kontrahenten tun sich nichts. Manchmal scheint es marginale Unterschiede zugunsten der Symbios-Treiber im Festplattenzugriff zu geben, manchmal zugunsten der Dawicontrol-Treiber in Bezug auf den CD-ROM-Zugriff. Insgesamt sind die Unterschiede derart gering, daß es allein durch die Ungenauigkeiten der Messungen schon erklärt werden kann. Um so interessanter wird dadurch aber der funktionale Unterschied - Beispiel: Symbios-Treiber, FixPak 12 und Device Driver Fixpak 2.

Seltsam. Bis hierhin war alles in Ordnung, jetzt spinnt der Controller schon beim Hochfahren: Etliche Male erfolgt ein SCSI-Bus-RESET und ein Scan der Geräte... und das permanent hintereinander. Das Booten dauert fast drei Minuten. Schließlich ist die WPS da. Ich greife auf das CD-ROM-Laufwerk zu: Wieder Reset, Scan, Reset, Scan... was macht der bloß?

Ich schaue mir mit <ALT-F2> beim erneuten Booten genervt das Desaster an... die Probleme beginnen beim Laden von OS2CDROM.DMD. Hmm... da könnte man doch mal versuchen... Ich ersetze ganz dreist den OS2CDROM.DMD in der config.sys durch den Freeware-Treiber JJSCDROM.DMD. Das hatte ich ohnehin vor, da mein Teac CD-532S sonst kein "Grabben" beherrscht - also das digitale Extrahieren der CD-Audiodaten.

Siehe da: Alles wieder in Butter. (Zwischenzeitlich habe ich auch erfahren, daß der OS2CDROM.DMD aus dem Device Driver Fixpak 2 Probleme mit manchen SCSI-CD-Laufwerken haben soll.)
 

Ergebnis der Treibertests:

Bis zum Aurora-Kernel sind die Treiber von Dawicontrol zu bevorzugen, da Sie problemlos mit dem OS2CDROM.DMD zusammenarbeiten, ab Aurora- (WSeB-) Kernel geht ohne die Symbios-Treiber nichts mehr - zumindest zum momentanen Stand nicht.

Da kann man auch verschmerzen, daß je nach eingesetztem FixPak-Level der OS2CDROM.DMD Probleme macht und man den JJSCDROM.DMD (Freeware) einsetzen muß. Für mich als Besitzer des Teac CD-532S ist er ohnehin zwingend, wenn ich DAE ("digital audio extraction") unter OS/2 will.

Ich muß zugeben, daß ich weder meinen Brenner getestet, noch den Scanner testhalber an den PC angeschlossen habe. Das mit dem Scanner werde ich auf jeden Fall separat angehen, denn diese Geräte sind (gerade unter OS/2) ein Fall für sich. Was den Brenner angeht, so muß ich gestehen, daß ich nur die CD-ROM-Funktionlität unter OS/2 betrachtet habe. Ich habe erfahren, daß es einige Leute gibt, die mit den Dawi-Treibern Probleme haben - gerade im Bereich Brennen und Scannen. Ob es hierbei zum Teil an den Geräten oder auch dem Rechner selbst liegt, kann ich nicht sagen, nur, daß die Probleme anscheinend durch Einsatz der Symbios-Treiber umgangen werden können.

Ein netter Nebeneffekt der Symbios-Treiber ist übrigens, daß in deren Lieferumfang ein "presence checker" für den Chip SYM53C875 enthalten ist - das Thema hatte ich ja bereits angesprochen. Wenn man die Datei SCSI.TBL entsprechend anpasst und SYM8XXPC.EXE angibt, wird der Controller automatisch erkannt und in der SCSI-Liste des OS/2-Installationsprogramms ausgewählt.

Dazu kommt auch, daß der Symbios-Treiber verglichen mit seinem Dawi-Pendant beim Laden zusätzlich noch die Firmware-Version des Gerätes anzeigt - eine nützliche Funktionalität übrigens. Ich habe damit z.B. herausgefunden, daß für meinen Teac CD-R56S ein Firmwareupdate existiert, mit dem ich CD-Text auf meinem Brenner verwenden kann. Nicht, daß ich das unbedingt bräuchte, aber... tja - ist doch nett, damit angeben zu können...;)

Abschließend möchte ich an dieser Stelle noch versprechen, daß ich dem Thema "Treiber, Scanner und Brenner" eine detaillierte Betrachtung widmen werde - darüber hinaus bin ich natürlich auch über E-Mail erreichbar und für Hinweise, Tips und Problemberichte zu diesen Themen dankbar. Gleiches gilt übrigens auch für Kommentare zu diesem Artikel.
 

Fazit:

Der Dawicontrol DC-2976UW bietet ordentliche Leistung zu einem sehr günstigen Preis von ca. DM 199,- und damit einem Drittel des Preises eines vergleichbaren Adaptec-Controllers.

• Für erfahrene OS/2-Anwender (bzw. "-Installateure") ist die Installation nicht sonderlich schwierig, für den Warp- oder SCSI-Neuling schon, da man sich die entsprechenden Anleitungen erst noch besorgen muß. Wahrscheinlich liegt in Zukunft die versprochene CD mit im Karton.
• Das BIOS enthält alle wichtigen Einstellungen, weitergehende Funktionen sind in einem DOS-Tool untergebracht, das auf der Treiberdiskette mitgeliefert wird.
• Die aktuell verfügbaren Treiber (4.21) von Dawicontrol sind nicht für FP14+ geeignet, was aber mit den Symbios-Treibern umgangen werden kann.
• Dawicontrol gewährt 5 Jahre Garantie auf seine Produkte, die telefonische Hotline ist kostenlos, war problemlos erreichbar und hat sich noch am selben Tag mit einer kompetenten Aussage zu einem OS/2-bezogenen Problem zurückgemeldet.
• Preislich und technisch gesehen kann der DC-2976UW seiner Konkurrenz allemal das Wasser reichen - schade nur, daß das bewährte Handbuch jetzt nicht mehr gedruckt beiliegt.

Dennoch kann ich das Produkt für OS/2 Heim- und SOHO-Anwender empfehlen - kurz gesagt: Kaufen Sie den Dawicontrol, nehmen Sie aber die Symbios-Treiber und den JJSCDROM.DMD, der als Freeware erhältlich ist - dann stehen Sie auf der Sonnenseite.