Crash, Linux, GA-EP45T Extreme, nohz und F5i

23.4.2010 von rmo.

Eine kleine Geschichte aus meinem Alltag, die ich mit einer rethorischen Frage beginnen möchte:

Ist Linux ist besser als Windows? Ja, unbedingt - aber …. Bei dem nachfolgend beschriebenen Erlebnis fühlte ich mich doch wieder an Schrecken aus längst vergangen geglaubten “Blue Screen” Zeiten erinnert.

Ich konnte das nachfolgende Problem zwar beseitigen, aber es war ein richtig ernsthafter Incident/Crash im laufenden Betrieb. Die Behebung glich dabei einer kleinen Odysee durch wenig befahrene Gewässer. Die Ursache des Crashes habe ich bis jetzt nicht verstanden. In den Logfiles ist nichts Ungewöhnliches zu finden. Irgendwie ist sowas nicht gut …..Vielleicht hat ja da draussen jemand einen kleinen Tipp für mich …. Ich möchte nicht an Viren unter Linux glauben ….

Mein Arbeitsplatz-PC beruht auf einem GA-EP45T Motherboard. Dieses Motherboard ist mit 8GB ausgestattet und hat bereits Opensuse 11.0, 11.1 und 11.2 und damit eine Reihe von 2.6.X Kernelversionen brav überstanden. Als Prozessor werkelt ein Q9550. Ich fahre das Board mit wirklich moderaten BIOS-Einstellungen (BIOS-Version 5Fi) und nutze das Enhanced Intel Speed Stepping. Die Graka ist eine Nvidia GeForce 9800 GTX+ -Variante. Ich fahre auf dem Desktop KDE 4 - aktuell KDE 4.4.2. Die aktuelle Kernelversion ist 2.6.31.12 - vor kurzem upgedated ! Meist laufen 1 bis 2 VMware Workstation-Instanzen im Hintergrund mit. Bis zur vergangenen Samstagnacht war das System nun über 1,5 Jahre hinweg auch unter Last ein sehr stabiles System (von den üblichen KDE 4 Kinderkrankheiten mal abgesehen).

Aber was geschah nun vergangenen Samstag ? Das System war ca. 2 Stunden sich selbst überlassen gewesen. Das Aktivieren eines Ruhezustands war aber nicht als Energesparoption eingestellt. Entsprechend reagierte das System zunächst auch ganz normal auf meine Bedienung. Dann aber wollte ich aus einem bestimmten Grund unter KDE eine neue Kontroll-Leiste einrichten. Das System stand dabei in keiner Weise unter Last. Temperatur, Lüfter etc. völlig in Ordnung. Plötzlich verhielt sich der Desktop merkwürdig. Stockender Bildaufbau, Verzögerungen in der Ausführung, Mausreaktion schlecht, etc.. Und dann begann das System aus heiterem Himmel neu zu booten.

Leider kam es dabei nicht weit - Grub war noch OK, dann erschien wie gewohnt der grafische Boot-Bildschirm von Opensuse 11.2 auf der Konsole - und das war es denn auch. Das System stand - gem. SUSE-Laufbalken offenbar noch weit vor der Analyse der Plattenpartitionen. Zudem war kein Wechsel vom grafischen Splash-Screen zum Textkonsolenmodus mehr möglich.

Nun habe ich für solche Zwischenfälle ja immer 2 voll lauffähige Linux-Systeme auf unterschiedlichen Partitionen installiert - also dachte ich mir: Kein Problem, dann bootest du halt das andere System und kümmerst dich von da aus um den Schaden (z.B. Fehler im Filesystem nach dem Crash) und dessen Ursachen. Aber da kam ich ganz genauso weit wie vorher - nämlich keinen Millimeter. Sprich: Das Laden des Kernels meiner zweiten Systemkonfiguration führte auch nicht zu einem ordentlichen Boot-Vorgang. Das war für mich dann schon ein ernstes Alarmsignal. Hier stimmte irgendetwas Grundlegendes nicht - und es war zumindest wahrscheinlich, dass das nichts mit einer defekten Partition zu tun hatte.

Also testweise ein dritter Anlauf: Konnte ich eigentlich noch ein neues System installieren ? Antwort: Nein! Auch der 64-Bit-Kernel, der von einer SUSE 11.2 initial für die Installationsphase geladen wurde, ließ sich nicht mehr installieren. Oh, oh, ….

Interessanterweise ware es aber noch möglich, das SuSE-Rettungssystem von der Installations-DVD zu starten und einige der wichtigen Ext3- und Ext4-Partitionen auf der Platte zu reparieren. Also Kernel in bestimmten Konfigurationen booteten doch ! Was sollte ich davon in meiner Verzweiflung halten? Hier denkt man zwangsläufig an ein Problem zwischen einem regulär parametrierten Kernel und dem Motherboard.

Nächster Schritt: Ich versuchte, das installierte System in der “sicheren” Variante zu starten. Dabei werden dem Kernel etliche Zusatzparameter übergeben, die bestimmte Features abschalten. Durch systematische Verringerung der Aufruf-Parameter stellte sich dann heraus, dass die Option “nohz=off” entscheidend war. Das ist ein interessanter Paramter, denn er hat etwas mit der Taktung des Systems zu tun (Tickless Kernel). Siehe etwa

http://www.phoronix.com/scan.php?page=article&item=651&num=1
http://kerneltrap.org/node/6750

Umgekehrt habe ich dann ins BIOS gesehen und versucht herauszufinden, ob ich dort etwas verändern konnte, so dass das System wieder bootete. Der Schlüssel war hier letztlich das Deaktivieren der CPU EIST Funktion ((Enhanced Intel SpeedStep Technology). Auch das half, das usprüngliche System wieder zum Booten zu bewegen - auch ohne “nohz=off”. Nun könnte man denken, dass etwas an der CPU fehlerhaft gewesen sein könnte. Dem stand aber entgegen, dass bei einem Boot mit aktiviertem EIST und “nohz=off” das Speedstepping einwandfrei funktionierte.

Zuletzt ein Blick auf die am Board angezeigten Post Error Codes des BIOS. Dort tauchte ein CXX-Zustand auf, der in der POST-Tabelle von Gigabyte nicht verzeichnet war.

Was nun? Irgendwie kam der Kernel wohl nicht mehr mit der Hardware klar. BIOS defekt ? Falsche BIOS-Version ? Hoppla, tatsächlich, ich finde ja plötzlich statt der gewohnten F5i-Version die ältere Bios-Version F4 vor! (Dafür gäbe es immerhin die Erklärung, dass die “Dual-Bios”-Absicherungsfunktion des Boards im Crash aktiviert wurde.) Ich entschloss mich deshalb, das BIOS mit der aktuellen Version “5Fi” zu flashen und danach erneut auf die gewohnten alten Werte einzustellen. Ich habe allerdings den C4/C4E Support bislang noch nicht wieder aktiviert.

Und siehe da: Danach lief das System wieder - ohne spezielle Kernelparameter beim Booten und mit aktiviertem EIST. Die ganze vergangene Woche ohne jede Einschränkung.

Das Merkwürdige: Im Nachhinein waren für den Zeitraum vor dem Crash keine zugehörigen besonderen Log-Einträge im System auszumachen - weit und breit nicht.

Die offenen Fragen:

1. Was um Himmels Willen löst einen solchen Crash im normalen Linux/KDE-Betrieb aus ? Gibt es ein Problem im Kernel oder liegt/lag einfach ein anderer Hardware-Defekt vor?
2. Wieso war dabei das BIOS betroffen?
3. Hat die übliche “Dual BIOS”-Absicherung des Gigabyte-Boards nach dem Crash tatsächlich automatisch ein Backup-Bios mit veränderten Einstellung in den Main-Bios-Chip eingespielt ?
4. Führt die C4/C4E-Aktivierung im BIOS zu irgendwelchen Problemen im aktuellen Kernel ? (Mit dem F5i-BIOS kann ich damit booten!).
5. Ist das “F5i”-BIOS notwendig, damit die aktuellen Kernel einwandfrei mit dem EP45T zusammenarbeiten?
6. Kommt ein unbekannter Virus unter Linux als Ursache in Frage ? Bitte nicht; an sowas möcht eich wirklich nicht mal denken ….

Tja, auch unter Linux kann man also bislang ungeahnte Crash-Welten erforschen ….

Wenn ich mehr weiss, melde ich mich wieder …. Hinweise nehme ich gerne über E-Mail entgegen.

Geschrieben in Hardware, Treiber, Erfahrungsberichte | Keine Kommentare »