Joerg Desch schrieb:
>
> Der Controller ist ein UW-SCSI Tekram 390-F (der mit NCR-Chips). An dem
> Ich habe die erste Seltsamkeit beim Booten gehabt. Hier hat das BIOS
> gemeckert, da� die 2. Platte (also die mit der Terminierung) "more than 64
> heads" hat. Tats�chlich lieferte das BIOS nur bei der ersten Platte die
> erwarteten Werte 4357/64/32. F�r die 2. Platte kamen 1020/141/62 heraus!
> Nach einem Tastendruck habe ich weitergemacht.
Vorsicht, viel Text :)
Nach einem Controllerwechsel Adaptec 2940UW auf Dawicontrol
2976UW hatte ich mal �hnliche Probleme. Dawicontrol/Symbios
schrieben damals in irgendeinem FAQ, dass man die Platten in
solchen F�llen am neuen Controller low-level-Formatieren solle.
Bei Dawi macht das das DOS-Proggi "SCSIFMT" und seitdem liefen
die Platten astrein.
In Deinem Fall ist jedoch eigenartig, da� der SCSI-Treiber
die korrekte Geometrie liefert, denn der Linux-Treiber f�r die
Symbios-Chips kennt von zwei Herstellern (Symbios/LSI und Tekram)
die Bios-Architektur und nutzt dann bei diesen per default die
vom Bios gemeldeten Werte (der Treiber zeigt an, ob er ein
unterst�tztes Bios gefunden hat und bei Deinem 390F sollte er
das tun). Das Bios des Dawi 2976UW erkennt der Treiber z.B.
nicht (gleicher Chip wie der 390F, n�mlich 875er Symbios/LSI)
und dann wird das benutzt, was die Platten melden.
Der 390F hat ein Flash-Bios - zieh Dir mal das aktuellste drauf,
mache im Zweifelsfall ein Low-Level-Format der Platten, nimm
unter Linux den sym53c8xx-Treiber (nicht den ncr53c8xx).
Wenn das auch nichts bringt kannst Du noch folgendes versuchen:
Klemme alle Ger�te an ein U160-Kabel mit aktivem Terminator am
Ende, schalte bei allen angeschlossenen Ger�ten die Terminierung
ab und Parity an, stecke f�r 50pol. Ger�te einen kleinen Zwischen-
adapter 68pol. auf 50pol. drauf und schaue, da� der SCSI-Bus nicht
l�nger als 1,5m ist. Der SCSI-Controller terminiert das eine Ende,
das andere Ende der aktive Terminator am Kabel. Ich habe die Er-
fahrung gemacht, da� es insbesondere die 53c875-UW-Chips *sehr*
genau mit der Terminierung und der Kabelqualit�t nehmen, egal von
welchem Hersteller der Controller ist. Das ging dann teilweise so
weit, da� f�r externe Ger�te wie ZIP oder Scanner ein zweiter
Controller eingebaut wurde, da das System nur so ordentlich lief.
> Woran kann das liegen? An einem anderen Board kann sich der Controller
> doch nicht st�ren? Und sein BIOS bringt der Tekram ja mit.
Doch, mit dem Board kann es Probleme geben: Das Shuttle Spacewalker
HOT-603 (Sockel 7, Chipsatz "AMD640" aka "VIA VP2/97", damals das
"Vorzeigest�ck" der Sockel 7-Szene, heute nur noch Erinnerungswert :)
l��t sich mit eingebautem SCSI-Controller mit 53x875-Chipsatz ohne
LILO-Parameter �berhaupt nicht booten - der sym53c8xx- oder der
ncr53c8xx-Treiber verf�ngt sich in einer Endlosschleife an
SCSI-Bus-Resets. L�sung ist das Abschalten der PCI-Master-Parity-
Pr�fung im SCSI-Treiber ("mpar:n"). Ich wei� leider bis heute nicht
ob das am MoBo-Chipsatz oder am Board-Bios liegt denn es gibt kein
anderes Mainboard mit diesem Chipsatz. Der SCSI-Controller ist
jedenfalls unschuldig - in anderen Boards funktioniert er auch ohne
diesen Parameter.
Erneuere auf jeden Fall mal das Bios vom Tekram und eventuell auch
das vom Board, dann Platten Low-Level (mit den Tekram-Tools oder
vielleicht kann das der Tekram auch per Bios - keine Ahnung), Ver-
kabelung pr�fen inkl. Terminierung, Parity, etc...
Gru�,
ab
--
To err is human; effective mayhem requires the root password!
--
--
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
