MO Drive an SCSI-Controller führt zu Installationsstillstand

Hallo!

Ich habe ein Problem bei der Installation von openSUSE 13.2 wie folgt:

• In meinem PC ist ein SCSI-Controller verbaut, daran hängt ein Fujitsu MO M2513A (ja, ich weiß, das ist sehr alte Hardware, kein SAS, sondern gutes, altes paralleles SCSI mit Flachbandkabeln).
• Booten von DVD, es laufen die ersten Zeilen der Konsole durch, der letzte Eintrag lautet "Starting udev...", dann steht die Kiste.
• Auf Konsole F3 sehe ich als letztes die folgenden Ausgaben:
  
  
  Code:

  Beginning domain validation
  Fast-20 SCSI 20.0MB/s ST (50ns, Offset 10)
  Abort operation started
  Abort operation timed-out
  Bus reset operation started
  Bus reset detected
  Bus has been reset
  Bus Reset completed
  Synchronizing SCSI cache

  Und das war's dann.
• Das Problem tritt nicht nur mit 13.2 auf, auch die Versionen davor waren bereits betroffen.
• Das Laufwerk hat früher (Suse 9.x oder so) mal unter Linux funktioniert.
• Das Problem ist nicht abhängig vom verwendeten SCSI-Controller, ich habe auch andere getestet. Derzeit hängt das MO an einem Dawicontrol DC-2976UW.
• Beim parallel installierten Windows 8.1 tritt das Problem nicht auf.
• Am SCSI-Bus hängen andere Devices, diese machen keine Probleme.
• Der Bus ist richtig terminiert, die Verkabelung ist OK, alles bereits durchgetestet (und unter Windows geht's ja).
• Ich habe im SCSI-Controller die ID an der das MO hängt testweise auf 5MBit/asynchronen Betrieb heruntergesetzt, das macht keinen Unterschied.
• Ich hatte früher openSUSE 13.0 installiert und dort das Problem mit dem MO ebenfalls. Ich habe dann das MO temporär vom SCSI-Bus getrennt und konnte SUSE installieren. Auch das installierte System hängte sich jedoch reproduzierbar auf, wenn man versucht hat es mit angeschlossenem MO zu booten. Ich gehe davon aus, dass der Effekt bei 13.2 identisch sein wird.
• Bei den damaligen Experimenten hatte ich teilweise den Effekt, dass das Laufwerk nach einem solchen Installationhänger auch unter Windows nicht mehr ansprechbar war und nur via Power-Cycle wieder reanimiert werden konnte. Offenbar geht das Problem hier soweit, dass sich die komplette Firmware des MO werghängt und dann den Bus blockiert, so dass Linux nicht booten kann.

Fragen jetzt:

• Kann ich via Kommandozeile irgendetwas konfigurieren? Z. B. das Device im Treiber auf asynchron zwingen oder das Laufwerk von der Erkennung am SCSI-Bus komplett ausschließen?
• Andere Möglichkeiten das Problem zu umgehen oder tiefer zu analysieren?
• Weiß jemand, ob sich bei den SCSI-Treibern im Vergleich zu "früher" (kann ich leider nicht genauer beziffern) irgendetwas geändert hat, was diesen Effekt hervorrufen könnte?
• Kann man den SCSI-Treiber beim Abfragen der vorhandenen Devices irgendwie kompatibler einstellen, so dass sich der Hänger evtl. vermeiden lässt?
• Für die Installation könnte ich das Laufwerk durchaus temporär abklemmen, aber dauerhaft ist das natürlich keine Lösung. Zur Not könnte ich mich sogar damit abfinden, dass das Laufwerk nicht unter Linux sondern nur unter Windows ansprechbar ist. Macht man halt die Rochade über Redmont um was zu schreiben/lesen. Nicht schön und toll, aber ein Notbehelf.
• Ehe nun andere Hardwareworkarounds vorgeschlagen werden, diese sind leider nicht möglich ("externes Gehäuse für das MO" geht nicht weil der Bus sonst zu lang wird, es hängt noch ein extern SCSI-Scanner dran; "zweiten SCSI-Controller einbauen" geht nicht wegen keinen freien PCI-Steckplätzen mehr, PCI-Steckplätze und PCIe-SCSI-Karten sind halt selten)

Was also kann ich tun/ausprobieren?

Thx!

Hi!
Wie ist die Busterminierung ausgeführt?Separater Terminating-Resistor oder über Jumpereinstellungen an den Endgeräten? Der Controller selbst darf ja nicht terminieren wenn an beiden Enden (intern und extern) Geräte dranhängen (und dahinter die eigentliche Terminierung,entweder im Gerät oder besser noch per separatem Terminating-Resistor),sonst gibts Datensalat auf dem Bus mit ähnlichen Folgen wie du sie beschreibst. Testhalber könntest du mal vorrübergehend den Scanner abklemmen und stattdessen die Terminierung auf dem Controller aktivieren,denn gerade Scanner machen ab und zu Murks mit der Terminierung (kenns von meinem Mustek 600 II CD Scanner her dem ich einen separaten Terminator angeflanscht hab genau aus dem Grund)....wenns dann läuft solltest du dir einen Terminierungsstecker für den 2. SCSI-Anschluß am Scanner besorgen und nutzen.

Hallo!

Die Busterminierung erfolgt über separate, aktive(!) Terminatoren an beiden Busenden, also wirklich dem letzten Pfostenstecker am internen Flachbandkabel und direkt am Ausgang des letzten externen Gerätes (es gibt aktuell nur ein externes Gerät, den Scanner). Der Controller selbst ist nicht terminiert, ebenso keines der angeschlossenen anderen Devices und das Buskabel ist auch nicht als "T" o. ä. groben Unfug ausgeführt worden. Sollte also passen, es sind auch keine Billigkabel verwendet worden. Ich habe alternativ zum derzeit genutzten Dawicontrol auch einen Tekram DC-390U2B/W in Betrieb gehabt und ich hatte in meinem früheren Rechner (der noch mehr PCI-Slots bot) auch die Konfiguration gefahren externe Geräte an einem Symbios 810 und die internen Devices an einem zweiten SCSI-Controller (damals erwähnter Tekram). All das hat leider keinen Unterschied gemacht.
Aktuell sind außer dem MO-Problem die anderen Devices auch problemlos nutzbar, intern sind noch zwei weitere Devices angeschlossen, diese funktionieren ohne Probleme, der externe Scanner ebenfalls. In der vorherigen Installation von SuSE ließ sich diese Konfiguration auch problemlos nutzen, *solange* das MO abgeklemmt war (AKA SCSI-Kabel am MO abgezogen, den Rest unverändert gelassen). Die aktuelle Konfiguration tut auch unter Windoze klaglos ihren Dienst (mit MO), von daher bin ich skeptisch, ob hier wirklich ein Busproblem vorliegt.

Ich wollte daher mal etwas anderes probieren und darauf bezog sich meine Frage: Kann ich

• auf der Kommandozeile der Installations-DVD verhindern, dass der SCSI-Treiber via Autodetect geladen wird?
• dem Treiber mitteilen, dass ein Device am SCSI-Bus nicht abgefragt werden soll?
• dem Treber mitteilen, dass ein bestimmtes Gerät (oder der gesamte Bus) nicht mit der maximal unterstützen Datenrate, sondern mit einer geringeren Rate gefahren werden soll?

Ich würde den Treiber gerne testweise mal auf 5MBit/s und asynchronen Betrieb zwingen, weil ich nicht sicher bin, dass eine diesebezügliche Einstellung im BIOS des Controllers vom SCSI-Treiber beachtet wird. Interessanterweise liefert das Programm HW-Info unter Windows als Angabe für das Laufwerk "SCSI-1", obwohl es lt. Datenblatt SCSI-2 angeblich fähig sein soll. Trifft die Angabe von HW-Info zu und kann das Gerät kein SCSI-2, würde vom Linux-Treiber jedoch irrigerweise mit SCSI-2 Geschwindigkeit angesprochen (die Konsolenausgaben lassen dies vermuten), wäre das auch eine denkbare Möglichkeit das Gerät zum Deadlock zu bringen. Das würde ich gerne gegentesten.

Aktive Terminierung an beiden Busenden? Kenne ich eigentlich nur von Wide bzw. Ultrawide SCSI (68-polige Leitungen statt 50-polige),bei SCSI 1+2 ist eigentlich Standard passive Terminatoren zu nutzen. Das MO-Drive aml an eine andere Position im Bus zu packen um eventuelle Kabelmacken auszuschließen hast du vermutlich schon gemacht,oder? Der Versuch mit abgeklemmten Scanner und den Controller mal die Terminierung des einen Endes machen zu lassen wäre das was ich mal als nächstes Probieren würde.

Betreffs Modultests beim booten der Install-DVD: MIt einer neu gemasterten DVD bei der das benötigte Kernelmodul direkt neben dem Kernel im Dateisystem liegt könnte man über die insmod= Direktive probieren ob da auch Parameter für das Kernelmodul mitübergeben werden können, theoretisch müsste es funktionieren, praktisch nutze ich ähnliches für manche Netzwerkkarten die oft nicht in der Standard-initrd der diversen Linuxdistributionen auf den Installmedien sind im Mosnis (PXELINUX als Netzwerkbootmanager verhält sich da analog zu ISOLINUX für das Booten von CD/DVD/BD ), allerdings hab ich da bisher noch keine speziellen Kernelmodulparameter benötigt sondern nur die Module an sich. Sofern also das genaue Kernelmodul und die Parameter für das Kernelmodul für deinen Controller bekannt sind die du ausprobieren willst ginge es durch editieren der isolinux.cfg und anpassen der Append-Zeile durch Einfügen weiterer Angaben nach folgendem Schema:
Zum Remastern wäre dann der Inhalt deiner Installations-DVD in einem Verzeichnis abzulegen, das benötigte Kernelmodul in der Version passend zum Kernel ausfindig zu machen und im Verzeichnis mit den DVD-Inhalten direkt dort abzulegen wo auch der Kernel liegt,dann die isolinux.cfg anzupassen und so wie in http://wiki.mosnis.de/Bootmanager-Wikibook/CD_und_DVD_Bootloader beschrieben das Iso-Image neu bootfähig zu erstellen und auf DVD zu brennen.

Hi,

nöh, aktive Terminatoren gibt's durchaus auch für Narrow SCSI.
Hier ein externer Typ:
http://pc-sonderposten.eu/product_info.php?products_id=3521
und hier ein interner:
http://www.pccables.com/cgi-bin/orders6.cgi?id=ID17565928&action=Showitem&partno=01115&rcode=
So was habe ich bei mit in Benutzung.

Passiv ist das übliche, korrekt, ich kenne noch Devices auf denen man schön kleine Widerstandsarrays stecken/ziehen konnte um die Terminierung zu schalten. ;-)
Ich hab bei mir aber irgendwann vor langer Zeit auf aktive Terminierung gewechselt, weil passiv halt doch schon mal Problemchen macht. Gerade wenn man an einem Kanal interne und externe Devices betreibt kann das schnell mal passieren, der Wellenwiderstand von internem Flachbandkabel und externem Rundkabel ist nie 100% gleich und dann hat man doch ein paar Reflektionen. Ein aktiv terminierter Bus läuft einfach deutlich stabiler, besonders bei großer Buslänge.

Bzgl. des Erstellens einer extra Boot-DVD: Puh, ganz schön aufwendig für ein wenig Probieren! Weiß nicht ob ich da so schnell die Zeit zu finde. Vielleicht spiele ich doch noch mal ein wenig mit dem Bus rum um zu schauen ob hier tatsächlich alles 100% grün ist.

Thx anyway!

Naja, der Grund für aktive Terminierung ist schon nachvollziehbar, habs halt bisher immer nur an einem Ende aktiv und am anderen dann passiv gesehen beim Wide-SCSI und beim Narrow eben bisher eigentlich auch nur passiv. Das mit den Arraygestöpsel kenne ich noch,aber ist harmlos gegen die Jumpermatrix an alten ESDI-Platten ...64 Jumper für eine Fujitsu 380 MB 5 1/4 Zoll Fullsize ESDI-Platte war eine regelrechte Jumperorgie gegen Anfang der 1990er Aber schnell waren die Dinger dafür,schneller noch als das SCSI 1 Zeugs zu der Zeit...nur halt technisch das Sackgassenende von MFM+RLL...

Betreffs em Remastern der DVD: Ist dann leider ötig weil das Kernelmodul per Appendzeile als Kernelparameter eben geladen würde bevor die initrd geladen wird,ergo muss es schon eher als die initrd verfügbar sein, und von USB-Stick laden ist mangels Mountoption für den Stick zu dem Zeitpunkt da ja auch noch nicht drin...könnte eventuell über eine floppydisk gemacht werden aber da müsste man erstmal gucken wies dann mit der Pfandangabe dahin im Bootloader (also ISOLINUX) zu dem Zeitpunkt steht...vielleicht findet sich dazu was auf http://www.syslinux.org ?
Eine andere Option wäre natürlich erstmal ohne das MO-Drive zu installieren und den Bootmanager der dann installiert ist dahingehend anzupassen,denn da dürfte man das Modul ja leichter eben rüberkopieren können (muss es dann nur bei eventuellen Kernelupdates jedesmal nochmal kopieren wenn man keinen Hardlink statt einer Kopie nutzt)...

Bei einer Installations- oder Live-DVD ist das Modul für den SCSI-Controller sicher dabei, somit kannst Du im Boot-Menü auch entsprechende Parameter mitgeben, aber das geht auch beim installierten System.

Welches Modul für den jeweiligen Controller verwendet wird, zeigt Dir: Welche Parameter möglich sind, kannst Du mit in Erfahrung bringen. Das Modul beim normalen System nicht zu laden, geht nur dann, wenn nicht von SCSI gestartet wird (blacklist-Eintragung und initrd-Neuerstellung).

P. S. In Sachen SCSI hat robi sicher ein paar Tricks auf Lager.

Bei so einer alten Möhre wirst du nicht drum rum kommen das an einen eigenen Kontroller zu hängen. der noch 5MB kann.
dann schauen, wenn ich mich nicht irre, dann hatte das Ding noch einen eigenen Terminiator. zu setzen als Jumper, diesen setzten und auf einen externen verzichten.

WEnn es dann nicht läuft, dann den Treiber für diesen Kontroller beim booten nicht zulassen, im Linux SCSI log anschalten, dann erst den Treiber laden. In Suse gibt es einen Befehl resetscsi oder so ähnlich, mit dem kannst du dann gezielt nach neuen Devices und Kontrollern suchen lassen.
Danach die Logs und SCSI-Logs mal anschauen.

Meistens ist das ein Terminatorproblem mit sochen alten Dingern und oft vertragen sich solche Dinger nicht mit Platten. Die Dinger waren in Jukeboxen und da waren sie unter sich am Bus, möglich die Firmware ist da nicht sonderlich flexibel genug um wirklich alles zu akzeptieren was SCSI spricht.

robi

Moin!

• Der eingesetzte Dawicontrol kann 5MB, zumindest behauptet das sein BIOS.
• Der Terminator des MO wird über ein Mäuseklavier aktiviert. Das MO hängt derzeit allerdings nicht am Ende der SCSI-Chain, müsste ich mal probeweise umbauen.
• Das MO wurde als separates Gerät gekauft und nicht aus einer Jukebox ausgebaut, hing also schon immer mit anderen zusammen an einem Bus. Über die Qualität der SCSI-Firmware sagt das natürlich nichts aus...

Mal schauen wann ich dazu komme weiter zu probieren, ich werde berichten...