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

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.

Mails im Ausland über deutsche SMTP-Server

Immer wieder begegnet man dem Problem, dass man bei Auslandsaufenthalten genötigt wird, für den Mailversand den SMTP-Server desjenigen Providers zu verwenden, an dessen Netzwerk man gerade angebunden ist. Ich stosse auf dieses Problem u.a. immer wieder in Norwegen (Telenor, Tele2) und Frankreich (Orange, France Telekom, Bouygues, Free(box)).

Die Provider filtern Zieladressen für eine SMTP-Kommunikation (Port 25), die sich nicht auf den Provider-eigenen SMTP-Server beziehen. Angeblich, weil man auf diesem Wege Spam-Probleme besser in den Griff bekommen will. Na ja, wer's glauben mag ....

Das Problem ist der dadurch für den Anwender generierte Aufwand. In der Regel hat man den Mail-Client (MUA, bei mir Kmail) auf seinem Notebook/Laptop ja so vorkonfiguriert, dass als SMTP-Server in der Regel ein Server des hauseigenen deutschen Providers eingestellt ist.

[Es kann aber auch auf Laptops noch komplizierter sein - nämlich dann, wenn ein eigener SMTP-Server, evtl. sogar ein lokaler SMTP-Server auf dem Laptop mit einer Relay-Server-Anbindung die SMTP-Kommunikation handhabt (z.B. in Form eines lokalen Postfix MTA mit einem IMAP MDA wie Cyrus) ].

In jedem Fall aber ärgert man sich bei Auslandsreisen jedesmal über die Notwendigkeit einer Re- oder Zusatzkonfiguration des Mail-Clients oder aber anderer Mailkomponenten (wie Postfix).

Am Schluss schleppt man eine Liste ausländischer SMTP-Server in seinen Mail-Programmen herum, aus der man je nach Standort einen bestimmten Server als den aktuellen Standard definieren muss. Schon bei manchen MUAs ist das ein Thema, denn der Mailclient sollte dann so intelligent ist, mehrere account-übergreifende SMTP-Server verwalten zu können ....

Bei einigen der ausländischen Netze habe ich deshalb mal mit einigen Linux-Tools überprüft, ob tatsächlich nur der Port 25 gefiltert wird. Dies war der Fall. Da kommt man dann auf den Gedanken, ob nicht ein anderer Port den Zugang zum SMTP-Server eines meiner deutschen Provider ermöglichen würde.

Man denkt dabei an eine TLS/SSL-Anbindung - in Frage kommen die Ports 465 und 587.

Und ja, tatsächlich ist bei zweien meiner deutschen Provider entweder der Port 465 (SMTP via SSL) oder der Port 587 zugänglich. Einer der Provider verwendet 465 in Kombination mit SMTP-AUTH, beim Port 587 ist eine Authentifizierung sowieso zwingend vorgeschrieben. Auf dem Mail-Client müssen dann natürlich die notwendigen Einstellungen für eine SMTP-Authentifizierung vorgenommen werden - was bei Kmail kein Problem darstellt.

Eine Anbindung über einen der beiden Ports 465 oder 587 kann man natürlich auch aus dem Inland vornehmen. Damit ist dann die Chance gegeben, im Inland wie auch in vielen ausländischen Netzwerken seinen Mailversand über den gewohnten SMTP-Server seines Vertrauens abzuwickeln. Standortspezifische Einstellungen entfallen dann. (Nebenbei finde ich, dass nicht jeden Provider mein Mail-Gebaren etwas angeht).

Nach meinen Erfahrungen klappt das Verwenden der Alternativports mindestens mal in Norwegen und Frankreich bestens - gefiltert wird dort nur der Port 25. Natürlich muss aber auch der eigene deutsche Provider mitspielen und die genannten Ports anbieten .....

Es lohnt sich bei häufigen Auslandsaufenthalten aber wirklich, das abzufragen und seine Mailprogramme (einmalig) auf einen der Ports 465 opder 587 umzustellen. Viel Spaß nun beim Mailen im Ausland !

Links:

http://de.wikipedia.org/wiki/E-Mail-Programm
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://de.wikipedia.org/wiki/SMTPS
http://de.wikipedia.org/wiki/SMTP-Auth
http://forum.df.eu/forum/showthread.php?t=49183