[openSuSE 12.1 und 12.2 MS2]Eigenartiger Fehler verhindert Installation

[ManfredP]

Hallo,
wollte openSuSE 12.1 installieren, komme aber gar nicht erst in die Installationsroutine. Der Grund: Der Bootvorgang des Installationssystems hängt sich in einer Schleife auf. Es beginnt, wenn ‘udev’ gestartet wird. Da kommt zuerst eine lange ‘Denkpause’ (man ist schon versucht, abzubrechen, weil es wie eine Blockade wirkt), dann beginnen die Fehlermeldungen. Sie laufen recht schnell durch und daher ist es schwer, den genauen Inhalt mitzubekommen. Auch ist dadurch nicht mehr festzustellen, wie alles beginnt.

Der Ablauf besteht aus 8 Fehlermeldungen, die sich ständig wiederholen. Alle stammen vom Programm ‘udevd’ und in der eckigen Klammer dahinter stehen verschiedene Zahlen rund um 100 (also 95 oder 106 oder so; aber nicht hochgezählt -bei einem neuerlichen Durchlauf sind es wieder die Gleichen wie vorher).

Der Fehler selbst lautet immer ‘timeout’ und bezieht sich ausschließlich auf das Kommando ‘/sbin/modprobe -bv’. Die Angaben dahinter variieren und sind recht kryptisch … daher nicht so schnell zu merken. Sie beginnen meistens ‘pci:v00001106d…’ oder usb:v0714p0005…’, einmal ist allerdings auch nur ‘sg’ zu sehen.

Eines ist mir allerdings aufgefallen: Die Nummern sind mir teilweise bekannt. Im USB-System gibt es zwei ID’s, die Vendor-ID und Product-ID genannt werden. Bei PCI heißen vergleichbare Nummern Vendor-ID und Device-ID. Das passt zu den Buchstaben in den Strings (v und p bzw. v und d). Tatsächlich gibt es in meinem Rechner Geräte mit entsprechenden ID’s, das sind bei pci der IDE und der S-ATA-Controller (Vendor-ID 1106 ist zum Beispiel VIA; der Chipsatz auf meinem MB ist ein KT-600 von VIA). Bei USB ist es ähnlich (die Angabe passt zum Gamepad). Daher werden sich diese kryptischen Strings wohl auf diese Bestandteile des Systems beziehen.

‘sg’ passt auch zu dieser Überlegung, da ich ein SCSI-System verwende und unter Anderem auch ein Bandlaufwerk (DAT) für Backups habe. Daher wird das SG-System (SCSI Generic) benötigt.

Da ‘modprobe’ für die Auffindung und Einbindung der Hardware zuständig ist, kommt es hier wohl zu Problemen bei Initialisierung derselben.

Meine Frage nun: Wie kann ich das umgehen? Bei 11.4 zum Beispiel war dies nicht vorhanden, also kann es nicht an der Hardware liegen. Auch Windows läuft mit dieser Hardware normal. Gibt es eine Möglichkeit, für die Initialisierung den modprobe einzuschränken? Eventuell (es betrifft ja nicht die gesamte Hardware; die SCSI-Adapter scheinen ja keine Probleme zu machen) ist für diese Hardware auch ein spezieller Treiber vorgesehen (Neu!) und ich könnte das System dazu bringen, den Alten zu verwenden.

Ach ja, Live-CDs können zum Teil (habe nicht alle durchprobiert!) starten, Aufhänger mit dem gleichen Problem hatte ich bisher nicht.

Zum System:
MSI KT6 Delta 6590 Ver 2.0 mit VIA KT-600A Chipsatz (Vendor-ID 1106, teilweise). AMD Athlon XP 3100+ CPU, 2 GB RAM (unbekannter Name), nVidia GeForce 6200 AGP (Vendor-ID 10DE, nein), Soundkarte (Aureal Vortex Chip Vendor-ID 12EB, unbekannt), Netzwerkkarte (RTL 8139 Chip; Vendor-ID 10EC, nein), 2 SCSI Adapter (53C1010-66 und 53C896; VLSI/SymBios Logic Chips; Vendor-ID 1000, nein)

Die Angaben ‘nein’ oder ‘unbekannt’ oder ‘teilweise’ beziehen sich auf das Fehlerverhalten von modprobe bzw. udevd.

USB-System: mehrere Hubs verschiedener Hersteller sowie ein Gamepad (NewMotion; OEM Conrad, Vendor-ID 0714, ja), ein Speicherkartenleser (36 in 1; in 4 ‘Laufwerke’ für die inkompatiblen Systeme wie CompactFlash und SD unterteilt; Vendor-ID 1019, nein), ein SAT-Receiver (Vendor-ID 3344, nein), ein Scanner (Vendor-ID 05D8, unbekannt), ein Centronics-Adapter (Vendor-ID 067B, unbekannt).

Da die Zeilen, wie erwähnt, schnell durchlaufen, musste ich praktisch lange nachlesen, um bestimmte Zahlen auschließen zu können. Das wurde auf die Dauer sehr mühsam, anstrengend und schwierig. Daher ist bei manchen IDs ‘unbekannt’ angegeben, das steht allerdings eher für ‘wohl eher nicht’, aber eben nicht gesichert. Die Anzahl der sich wiederholenden Zeilen schließt allerdings eine gewisse Anzahl von Kombinationen der als ‘unbekannt’ aufgeführten Geräte aus.

Ich hoffe, jemand hat eine Idee, wie ich das System anlaufen lassen kann.

Tschüß

Manfred

[matchi]

Hi Manfred,

um z Bsp. das sg Modul nicht automatisch laden zu lassen, verwende

BrokenModules=sg

als boot Parameter. Das klappt auch für alle anderen Module, einfach mit Komma trennen.

[ManfredP]

Hallo,
danke. Das Problem mit sg bekomme ich damit schon mal in den Griff. Das Gamepad kann ich rausziehen, das ist also auch kein Problem. Bei den anderen Zeilen wird’s schon schwieriger. Denn wie heißen die module, die ich da abschalten muss? Aus der Zeile ist es nicht ersichtlich. Da ich ja eben kein Linux am Laufen habe, kann ich auch nicht nachsehen. Ein Glück ist, dass ich SCSI verwende und IDE sowie S-ATA nur am Rande. Dadurch kann ich die Module abschalten und habe dennoch was, um die Installation draufzupacken (es nützt wenig, das Modul des Boot-Devices abzuschalten).

Ich werde das auf jeden Fall mal ausprobieren.

Tschüß

Manfred

[ManfredP]

Hallo,
hab’s mit IDE, USB und S-ATA mal zuerst ganz simpel probiert: Ausschalten im BIOS, die Sachen sind in meinem vordringlich SCSI-System nicht essentuell. Das war schon mal ein Erfolg. sg mit BrokenModules, da ging’s. Sehr viel weiter bin ich immer noch nicht, aber das ist eine andere Geschichte (anderer Thread).

Damit dann Danke und Tschüß

Manfred

[ManfredP]

Hallo,
ein Nachtrag zu diesem Thread.

Folgendes habe ich probiert: Ich habe im BIOS sowohl S-ATA als auch P-ATA abgeschaltet. Die Version mit BrokenModules funktionierte leider nicht, da ich, mangels Boot, den genauen Namen der betroffenen Module nicht herausfinden konnte und ohne Den (und zwar buchstabengenau) kommt man nun mal hier nicht weiter.

Zum Glück beachtet Linux derartige Abschaltungen und reagiert auch entsprechend (da die Geräte ja weiterhin vorhanden sein dürften, hielt ich das nicht für selbstverständlich … möglicherweise irre ich mich hier). Unter diesen Umständen funktionierte das Booten und sogar die Einbindung von ‘sg’ war wieder möglich. Dies zeigte mir, dass zumindest ein Teil der Fehlermeldungen auf indirekte Fehler zurückging, die gar nichts mit dem eigentlichen Problem zu tun haben

Daher ging ich in einem zweiten Schritt so vor, dass ich nur eines der beiden Systeme abschaltete. Mit S-ATA an und P-ATA aus funktionierte es nicht, wohl aber umgekehrt. Also ist S-ATA der Übeltäter. Dann habe ich die Fehlermeldungen im Internet recherchiert (dieses timeout irgendwas modprobe -bv irgendwas) und dabei auch einige, ältere Antworten in anderen Foren gefunden (eine erste Recherche einige Tage zuvor brachte kein Ergebnis; wohl ein Tippfehler in der langen und komplizierten Fehlermeldung beim Übertragen in Google :shame:). Demnach ist die Situation folgende:
Irgendwie muss modprobe wohl vom Kernel eine passende Reaktion erhalten und dafür muss der Kernel wiederum die Nummern der Geräte, die in dem modprobe-Parameter enthalten sind, kennen (v- und p-Nummern). Handelt es sich um unbekannte Nummern, so kann der Kernel nicht entsprechend reagieren und modprobe hängt sich auf. So wenigstens habe ich die Texte verstanden, sie waren teilweise auf englisch, setzten einen Teil der notwendigen Vorkenntnisse beim Leser voraus und waren zum Teil auch voller Tippfehler usw., die das Lesen erschwerten.
Da das Mainboard schon älter ist, kann der Parameter hier eigentlich nicht unbekannt sein (die Hardware gibt’s schon 'ne Weile). Den Zusammenhang sehe ich im Moment noch nicht so wirklich. Auch die Tatsache, dass gleich mehrere Fehlermeldungen auftreten, die verschwinden, sobald auch nur ein Teilsystem deaktiviert (auch, wenn sie eigentlich ein ganz anderes Teilsystem betreffen) ist irgendwie unverständlich.

Leider konnte ich zu diesem Optionsparameter -b für modprobe noch immer nichts erfahren (v steht für verbose, wie fast immer). Eventuell steht das für Boot und daher habe ich dieses Kommando auch nicht einfach auf der Shell ausprobiert … ich wollte vermeiden, dass dadurch die Hardware am Ende total verstellt wird -sowas hat mich schon einmal zum Wegwerfen der betroffenen Hardware gezwungen -vor einiger Zeit- weil kein Treiber oder was auch immer der verstellten Hardware den Weg zurück erlaubte :eek:

Versuchsweise habe ich dann aber noch einen weiteren Test gemacht. Immerhin wollte ich ja auch kein System, bei dem ich beim Booten jedes Mal das BIOS zu verstellen habe, denn auf der S-ATA-Platte ist zum Beispiel das Download-Verzeichnis von Windows untergebracht. Zum Booten brauche ich die Platte nicht, aber ohne sie wäre das System nicht vollständig. Es gibt bei diesem S-ATA-System (auf dem Mainboard) einen zusätzlichen BIOS-Parameter, der den sog. V-Link Data 2x Support aktiviert (an ist der default). Ich weis nicht, was dieser Parameter bewirken soll, doch weil da was von 2x (also wohl zwei mal) drin steht, nahm ich an, es handelt sich um einen Beschleunigungseffekt. Denn habe ich abgeschaltet. Nun geht’s auch mit eingeschaltetem S-ATA und die Platte ist erreichbar.

Noch eine Anmerkung zu dieser Geschichte: Die Fehlermeldungen liefen immer auf der ersten virtuellen Konsole durch und wenn man zu früh auf einen andere Konsole umschaltete, wurde der Fehler auf dieser anderen Konsole angezeigt, was die Meldungen dort dann überlagerte. Dadurch habe ich eine parallele Fehlermeldung im Logging-Fenster auf Konsole drei längere Zeit nicht entdeckt. Sie lautet

ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:<07:01>:00:00:00:00:00:00:00/e0 tag 0 dma <3584> in res: 40/00:00:00:00:00 \
/00:00:00:00:00/00 EMask 0x4 (timeout)
ata1.00: status: {DRDY}
ata1: soft resetting
ata1.00: configured for UDMA/33
ata1.00: device reported invalid CHS sector 0
ata1: EH complete

dann wiederholt sich das Ganze. Im Code steht an einer Stelle <07:01> und an anderer Stelle <3584>. Die spitzen Klammern tauchen im echten Text hier nicht auf. Vielmehr sollen sie andeuten, das der Teil zwischen diesen Klammern nicht immer gleich lautet. Es kommt auch vor, dass dort ‘08:00’ und ‘4096’ oder was Anderes steht. Die Zahlen sind immer korreliert, das bedeutet, dass immer 08:00 mit 4096 kombiniert ist und entsprechend.

Was die Fehlermeldung genau ausdrückt, habe ich noch nicht ganz verstanden, aber soviel weis ich zumindest: Hier ging ein Leseversuch von der Platte daneben. Offenbar sollte der Lesevorgang über DMA laufen und ist abgestürzt. Das System wird daraufhin via Reset-Befehl zurückgeschaltet und es dann erneut versucht (bedauerlicherweise immer wieder ohne Ende >:().

Des Weiteren ist klar, dass das Ganze den Sektor Null dieser Platte, also die Partitionstabelle (der Bootsektor/MBR ist hier an dieser Stelle ja unwichtig) betrifft. Die ist aber unter Windows eindeutig verfügbar und weist keine Fehler auf. Da ich ja nicht feststellen konnte, was der Kernel so treibt, wusste ich auch lange nicht, welche Platte ata.00 eigentlich ist, es dürfte sich aber wohl um die S-ATA-Platte handeln -deshalb geht es, sobald S-ATA abgeschaltet ist.

Durch diese Meldung kam ich dann auf den Gedanken, dass irgendwas im System zu schnell läuft und daher die Platte oder den Treiber überrennt. Dazu würde auch ‘lost interrupt’ passen (heißt ja immerhin, das ein unbehandelter Interrupt stattgefunden hat; der Rechner war also nicht schnell genug, den Interrupt-Service-Handler aufzurufen, bevor der nächste Interupt auf der gleichen Leitung auftrat).

Das unter Windows der Fehler nicht auftritt, muss nichts heißen, da das ja auch von der Art der Programmierung des Treibers abhängig sein kann (eventuell handelt es sich ja um eine Race-Condition zwischen Treiber und Hardware). Die Abschaltung dieses V-Link so-und-so hat, so vermute ich, das System gebremst und dadurch das Rennen abgewürgt.

Nun also ist der Fehler quasi beseitigt (zumindest gibt es einen praktikablen Work-Around). Das ich dies so ausführlich schreibe, hängt auch mit den anderen Forumsbeiträgen in anderen Foren zusammen, die ich über Google fand. Denn ihre reine Anzahl beweist schon, dass der Fehler keineswegs so selten auftritt, wie ich ursprünglich annahm. Diese Schilderung kann dann vielleicht anderen Betroffenen helfen.

Tschüß

Manfred

[ManfredP]

Hallo,
noch eine Ergänzung.

Habe auch die BIOS-Option noch mal bei Google eingegeben. Nach einigen Fehl-Versuchen kam dann doch noch was Vernünftiges dabei heraus. Also: V-Link ist eine Verbindung zwischen dem IDE/S-ATA-Host-Adaper und der South-Bridge des Chipsatzes (auch die North-Bridge läuft über so einen V-Link, scheint aber ein Anderer zu sein, da diese Verbindung eine eigene Frequnez-Einstellung besitzt; zumindest bei manchen Mainboards). Der läuft hier mit der doppelten Geschwindigkeit des PCI. Wenn die Option abgeschaltet wird, wird statt dessen der normale PCI verwendet. Ein Forumsartikel, den Google gefunden hat, berichtet von Inkompatibilitäten zwischen dem Host-Adapter und einigen Platten, die bei der normalen Arbeitsweise (mit V-Link) zu Problemen (Boot-Probleme (!!!) und sogar Datenverlusten) führen. Wegen dieser Probleme wurde diese zusätzliche Option eingeführt, die aus irgend einem Grund aber mit dem S-ATA-Zweig des Host-Adapters gekoppelt wurde (die Option kann nur verändert werden, wenn der S-ATA-Zweig an ist), obwohl der V-Link ja für Beide gilt.

Da dieser V-Link, so wie ich die Beschreibung verstanden habe, ein serieller Bus ähnlich PCI-Express (will man mehr Daten übertragen, werden kurzerhand mehrere komplette Busse, sog. Lanes, parallel geschaltet) ist, dürfte er zum Beispiel keine Interrupt-Leitungen enthalten. Die laufen also gewissermaßen außen herum durch den PCI. Eventuell deshalb tauchte da die Fehlermeldung über ‘lost interrupt’ auf.

Interrupts können allerdings tatsächlich nur auf zwei Arten verloren gehen: Wenn die Interrupt-Service-Routine nicht re-entrant ist, also nicht während einer laufenden Routine diese erneut aufgerufen werden darf und wenn die Interrupts aus irgendwelchen Gründen zeitweise abgeschaltet wurden und während dieser Zeit mehr als einmal ein entsprechender Interrupt einging (weil im Interrupt-System kein Zähler die Anzahl der Interrupts ermitteln kann). Auf die Art wird dann auch die Treiber- und damit Betriebssystemabhängigkeit (zumindest als Möglichkeit) erklärt, denn solche Sachen macht natürlich jeder Programmierer anders.

Tschüß

Manfred