Opensuse 11.4, XEN, Nvidia, uvesafb

21.5.2011 von rmo.

Wie bekommt man auf einem System mit einer Nvidia-Karte

• Opensuse 11.4,
• den zugehörigen XEN-Kernel
• und einen graphischen Desktop mit 3D-Beschleunigung in der Dom0 des XEN-Systems

zum Laufen ?

Dieses Thema mag auf den ersten Blick fast esoterisch erscheien. Aber es gibt tatsächlich Entwickler für graphische Applikationen, die auf einem System virtualisierte Gäste laufen lassen und gleichzeitig in der Dom0 3D-Grafik betreiben wollen.

Siehe auch:
http://www.nvnews.net/vbulletin/showthread.php?t=60125

Ferner ist es so, dass man bei einem laufenden 3D-beschleunigten X-Server (z.B. in der Dom0) auch 3D-Output der virtuellen Maschinen beschleunigt darstellen kann: Das X-System beherrscht ja schon seit langem beschleunigten 3D-Ouput auch über ein Netzwerk.
Also kann man den graphischen Output der virtuellen Maschine über das (virtuelle gebridgte) Netzwerk des Hosts auch auf dem X-Server des Hosts beschleunigt darstellen. Bei einem leistungsstarken System geht das besser als man meinen möchte. Dazu mehr in einem künftigen Beitrag.

Ich habe selbst schon vor 3 Jhren bei meinen ersten Versuchen mit XEN Anläufe unternommen, um eine 3D-Beschleunigung mit Nvidia-Karten in der Dom0 irgendwie und halbwegs stabil hinzubekommen. Aber ich bin regelmäßig gescheitert. Nun hat sich inzwischen aber einiges getan (s. das oben angegebene Forum) und jetzt hat es endlich auch auf meinen XEN-Systemen unter Opensuse 11.4 so funktioniert wie ich mir das vorstelle. Meinen Lösungsansatz findet ihr im Original unter

http://www.nvnews.net/vbulletin/showthread.php?t=60125&page=10

als Beitrag des Users “moenchmeyer”.

Hier stelle ich als Ergänzung eine deutsche Variante der von mir angegebenen Schritte ins Netz.

Das Testsystem von mir hat einen Q9550 Quad Core Prozessor einen Raid10 Plattenverbund und eine Nvidia 9800 GTX+ Grafikkarte sowie 8 GByte RAM. Es wird als 64-Bit-System mit den entsprechenden x86_64-Kernelvarianten und Kernelmodulen betrieben.

Es sind zwei Hürden zu überwinden :

1. Die Installation (inkl. Kompilation) des Nvidia-Treibers für den XEN-Kernel von Opensuse 11.4
2. Der Einsatz von “uvesafb” statt des normalen Vesa Framebuffer-Verfahrens für die TTYs tty1 bis tty6 des XEN hosts.

Ohne Punkt 2 erhält man beim Umschalten von der graphischen Desktop-Umgebung, die typischerweise auf tty7 läuft, zu einem der textorientierten Terminals (tty1 bis tty6, tty10) nämlich nur schwarze Schirme. Und das mag zumindest ich nicht. Wie also kann man das vermeiden?

Schritt 1: Installation von Opensuse 11.4 mit den Xen und Virtualisierungspaketen (libvirt etc.)

Man installiere auf dem künftigen XEN-System Opensuse 11.4 zunächst ganz regulär. Vor dem eigentlichen Installationsvorgang wählt man bei der SW-PaketKonfiguration am besten gleich die Option “hostserver für Xen Virtual Machine” aus. Dann spart man sich die spätere Nach-Installation. Zusätzlich installiert man die notwendigen Compiler und Zutaten einer elementaren Entwicklungsumgebung sowie die Kernelquellen, um später Kernelmodule kompilieren zu können.

Schritt 2: Installationsversuch bzgl. des Nvidia-Kernel-Moduls nach dem Booten des Default-Kernels (nicht des Xen-Kernels)

Auf dem frisch installierten System werkelt der Nouveau-Treiber für Nvidia-Karten und erlaubt den Zugang zu einer graphischen Desktop-Umgebung. Im Gegensatz zum proprietären Nvidia-Treiber erlaubt dieser offene Treiber aber keine 3D-Beschleunigung. Daher holen wir uns nun den aktuellen Nvidia-Treiber (270.41.06) vom Nvidia-Portal.

Anschließend wechseln wir in den “runlevel 3″. Dort starten wir im Verzeichnis mit dem Treiber die Installation:

sh NVIDIA-Linux-x86_64-270.41.06.run

Diese schlägt fehl - die Installationsroutine beklagt sich über den bereits laufenden Nouveau-Treiber. Die Frage, ob ein File zur Deaktivierung des Nouveau-Treibers installiert werden soll, beantworten wir positiv.

Schritt 3: Deaktivierung von KMS und Installation des Nvidia-Kernel-Moduls für den Default-Kernel (nicht Xen-Kernel)

Wir deaktivieren nun KMS - z.B. mit Hilfe von YAST und des dortigen Editors für die Files in “/etc/sysconfig”. Wir setzen die Option “NO_KMS_INITRD” unter “system > kernel” auf “yes”. (Alternativ kann man den Eintrag auch direkt im File “/etc/sysconfig/kernel” editieren.)

Anschließend führen wir einen Reboot in den Runlevel 3 durch. Dabei setzen wir im Menü des Grub Bootloaders neben “linux 3″ noch den Parameter “nomodeset” - dann sind wir hinsichtlich der Deaktivierung von KMS auf der sicheren Seite.

Jetzt steht einer erfolgreichen Installation des NvidiaTreibers nichts mehr im Wege. Wir führen sie durch, wechseln danach in den Runlevel 5 und testen das korrekte Arbeiten der 3D-Beschleunigung in unserer grafischen Desktop-Umgebung über “glxinfo” oder die Einstellungen in der Applikation “nvidia-settings”. Natürlich können wir auch mal “glxgears” staren oder einen 3D-Effekt des KDE-Desktops anschalten.

Damit haben wir uns von der Funktionstüchtigkeit des Nvidia-Treibers für den normalen Kernel des Opensuse 11.4-Systems überzeugt. Jetzt kann man auch die Pakete für den Nouveau-Treiber deinstallieren - wenn man will.

Schritt 4: Booten des XEN-Kernels und Installation des Nvidiatreibers in der Dom0
Wir rebooten das System. Im Grub-Menü wählen wir nun aber die Option für den XEN-Kernel und geben erneut “linux 3″ als Option an, um in den Runlevel 3 zu gelangen. Ein Booten in den Runlevel 5 würde scheitern, da der Nvidia-Treiber bislang nicht für den XEN-Kernel kompliert wurde.

Im Runlevel 3 führen wir daher die Installation des Nvidia-Treibers erneut durch - diesmal aber mit einer speziellen Art der Kompilation:

cd Your_Directory_With_THE_Nvidia_Driver
export IGNORE_XEN_PRESENCE=1 SYSSRC=/usr/src/linux-2.6.37.6-0.5 SYSOUT=/usr/src/linux-2.6.37.6-0.5-obj/x86_64/xen

sh ./NVIDIA-Linux-x86_64-270.41.06.run

Die Environment-Variablen IGNORE_XEN_PRESENCE, SYSSRC und SYSOUT werden von der Installationsroutine ausgewertet: Die Präsenz des XEN-Kernels wird ignoriert, die Kompilation erfolgt gegen die Sourcen und Einstellungen des Standard-Kernels - der resultierend Output (das Modul) wird aber gem. der Vorgaben für den XEN-Kernel gelinkt und installiert.

Die Versionsangaben in den obigen Statements müssen ggf. an die tatsächlichen Verhältnissen auf dem System angepasst werden. Sie gelten wie angegeben nur für eine Opensuse 11.4 Installation ohne Kernel-Updates.

Nun haben wir ein geeignetes und bereits geladenes Nvidia-Kernelmodul in der Dom0.

Schritt 5: Starten des X-Servers durch Wechsel in den Runlevel 5
Wir wechseln nun in den Runlevel 5 (init 5). Der XServer sollte anstandslos auf dem tty7 starten. Wir können uns dort einloggen und uns von der Funktionstüchtigkeit der 3D-Beschleunigung überzeugen. Damit ist die erste Hürde für den XEN-Kernel genommen.

Unglücklicherweise hat die Sache einen gravierenden Makel:

Ein Wechsel von der graphischen Oberfläche zu einem der textorientierten Terminals tty1 bis tty6 führt zu schwarzen Bildschirmen. Hier lernen wir gerade die 2te Hürde kennen: Die Ausgabe des angesprungenen Terminals wird nicht auf dem Schirm dargestellt und ist somit nicht sichtbar - obwohl die Terminals als Prozesse faktisch aktiv sind und sogar auf Tastatureingaben reagieren. So ist ein Wechsel zum grafischen tty7 jederzeit durch CTRL ALT F7 oder durch ein Einloggen im Blindflug und anschließendes Tippen von “chvt 7″ möglich.

Schritt 6: Prüfe die Existenz des Moduls “uvesafb”
Wieder in unserer grafischen Umgebung angelangt, überzeugen wir uns davon, dass das Modul “uvesafb.ko” im Verzeichnis “/lib/modules/2.6.37.6-0.5-xen/kernel/drivers/video” vorhanden ist.

Opensuse’s XEN-Kernel ist zusammen mit diesem Modul kompiliert und installiert worden. Das Modul sollte also an seinem Platz zu finden sein. Wenn nicht, bleibt leider nichts anderes übrig, als selbst den Kernel zusammen mit diesem Modul neu zu konfigurieren, zu kompilieren und zu implementieren.

Schritt 7: Installation von “v86d”
“uvesafb” benötigt für seinen Einsatz zwingend den sogenannten Helper Daemon “v86d”. Dieser Daemon ermittelt Daten zum Framebuffer System der Grafikkarte und den Fähigkeiten des Schirms. Ohne “v86d” läuft “uvesafb” nicht !

Leider gibt es zu “v86d” kein geeignetes RPM-Paket, das sich unter Opensuse 11.4 installieren ließe. Zumindest habe ich keines gefunden.

Also müssen wir uns die Sourcecodes besorgen - und zwar von folgender Adresse:

http://dev.gentoo.org/~spock/projects/uvesafb/

Wir laden uns das Archiv “v86d0.1.10.tar.bz2″ herunter und expandieren es in einem Verzeichnis unserer Wahl. Wir wechseln dorthin und führen dann die Stadardschritte “./configure” und “make” durch. “./configure” ergänzen wir dabei um die Option “–with-x86emu”.

Die Kompilation und das Linken sollten problemfrei vor sich gehen. Das resultierende Executable “v86d” kopieren wir dann als root in das Verzeichnis “/sbin/”.

Schritt 8: Identifizieren möglicher “uvesafb”-Modes”
Wir informieren uns über mögliche “uvesafb”-Modes durch Absetzen des Befehls

cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes

an irgendeinem Pseudo-Terminal der grafischen Oberfläche.

Schritt 9: Konfigurationsdatei für das “uvesafb”-Modul
Als root erzeugen wir nun ein File “uvesafb.conf” im Verzeichnis “/etc/modprobe.d/”. Wir legen dann den künftig von uns gewünschten “uvesafb”-Modus für die TTYs - z.B. den Modus 1280×800-32 - fest, indem wir folgende Zeile in die Datei einfügen:

options uvesafb mode_option=1280×800-32 scroll=ywrap

Schritt 10: Eliminieren aller Vesa “vga”-Parameter aus der Bootloader-Konfiguration
Als nächstes ändern wir unsere Grub Bootloader-Konfiguration. Dazu könen wir Yast benutze oder aber die Konfigurationsdateien unter “/boot/grub” auch direkt editieren:

Wir eliminieren aus den Zeilen, die den Grub-Eintrag für das Booten des XEN-Kerels beschreiben, alle “vga”-Parameter - etwa “vga=mode-0xnnn” oder “vga=0xnnn”. “nnn” steht hier für den bei der Installation des SUSE-Systems festgelegten Standard VESA Framebuffer Modus für die TTYs.

Diese Entfernung der vga-Paramter ist ein sehr wichtiger Schritt: Die Vesa-Modes sind mit den “uvesafb”-Modes nicht kompatibel. Ein Starten der Standard-Vesa-Modes würde später ein erfolgreiches Laden des “uvesafb”-Moduls und ein Setzen des gewünschten “uvesafb”-Modus verhindern! Das Standard Vesa Setup ist nicht mit “uvesafb” verträglich !

Schritt 11: Erneutes Booten des XEN-Kernels und Laden des “uvesafb”-Moduls
Wir booten den XEN-Kernel erneut in den Runlevel 3. Da wir die vga-Optionen eliminiert haben, erschienen die Boot-Meldungen nun natürlich in der wenig ansehnlichen Terminal-Auflösung von 80×25 Spalten/Zeilen. Davon lassen wir uns aber nicht abschrecken, denn gleich werden wir unseren “uvesafb”-Modus anschalten.

Im Runlevel 3 loggen wir uns als root ein und versuchen dann, das “uvesafb”-Modul zu laden:

modprobe uvesafb

Das Terminal-Layout sollte sich nun deutlich zum Besseren ändern. Zur Sicherheit (oder im Fehlerfall zur Analyse) sehen wir uns nun die letzten Meldungen in “/var/log/messages” zum Laden des Moduls an. “uvesafb” sollte nicht nur geladen worden sein - der “v86d”-Daemon sollte relevante Information zur Vesa-Implementierung der Graka und zu Schirm verraten haben. Ferner sollte der Speicherpunkt für den Modus gesetzt worden sein.

May 20 17:24:50 xen kernel: [ 27.172094] uvesafb: NVIDIA Corporation, G92 Board - 03910050, Chip Rev , OEM: NVIDIA, VBE v3.0
May 20 17:24:50 xen kernel: [ 27.288417] uvesafb: VBIOS/hardware supports DDC2 transfers
May 20 17:24:50 xen kernel: [ 27.445892] uvesafb: monitor limits: vf = 75 Hz, hf = 94 kHz, clk = 210 MHz
May 20 17:24:50 xen kernel: [ 27.446342] uvesafb: scrolling: redraw
May 20 17:24:50 xen kernel: [ 27.838652] Console: switching to colour frame buffer device 160×64
May 20 17:24:50 xen kernel: [ 27.870389] uvesafb: framebuffer at 0xf7000000, mapped to 0xffffc90005980000, using 14336k, total 14336k
May 20 17:24:50 xen kernel: [ 27.870390] fb0: VESA VGA frame buffer device

Durch “CTRL ALT Fx” probieren wir nun, ob wir zwischen den TTYs tty1 bis tty6 hn und her wechseln können und das alle Terminals sich im gleichen “uvesafb”-Modus präsentieren.

Schritt 12: Wechsel zwischen der 3D-beschleunigten grafischen Oberfläche der Dom0 und den TTYs im Framebuffer-Modus
Abschließend starten wir nun den Runlevel 5, loggen uns in die grafische Desktop-Umgebung ein, die ja wegen des Nvidia-Treibers 3D-beschleunigt ist. Dort probieren jetzt einen Wechsel zu den anderen TTYs - z.B. zum Konsolen-Terminal tty1. Das sollte nun anstandslos klappen - der Output des Terminals tty1 muss sichtbar sein (im gewählten “uvesafb”-Modus). Auch eine Wechsel zurück zum tty7 sollte nun problemfrei funktionieren.

Damit haben wir unser Ziel erreicht. In der XEN Dom0 von Opensuse 11.4 läuft nun der prorietäre Nvidia-Treiber und verhilft uns zum Genuß einer grafischen Oberfläche mit 3D-Beschleunigung. Zudem können wir den uvesafb-Framebuffer-Modus unserer anderen TTYs über eine Konfigurationsdatei kontrollieren und wie gewohnt zwischen allen Terminals hin und her wechseln.

Bleibt nur noch, den Bootvorgang in den Runlevel 5 durch Manipulation entsprechender Startup-Skripts zu automatisieren. Wir müssen eigentlich nur dafür sorgen, dass das “uvesafb”-Modul vor dem Starten des X-Servers geladen wird. Das führen wir hier aber nicht weiter aus, sondern überlassen es dem Leser, das durch ein entsprechendes Skript unter /etc/init.d/rc5d hinzubekommen.

Nützliche Links:
https://wiki.archlinux.org/index.php/Uvesafb
http://dev.gentoo.org/~spock/projects/uvesafb/

Viel Spaß nun mit XEN und einer grafischen Desktopumgebung der Dom0, bei der auch 3D-Effekte und 3D-Programme hardware-beschleunigt laufen.

Geschrieben in Xen und KVM, Hardware, Treiber, Linux 3D Desktop | Keine Kommentare »

9650SE-4LPML - ein paar Einstellungen

9.9.2010 von rmo.

Wenn man mit einer oder mehreren VMware-Workstation unter Linux hantiert, ist man froh über einen guten I/O. Gestern hat mich jemand in diesem Zusammenhang auf meine Erfahrungen mit 3ware-Controllern angesprochen.

Pauschal konnte und kann ich darauf nicht antworten - man müsste für eine solide Einschätzung systematische Vergleiche mit anderen Controllern durchführen. Dazu fehlen mir im Moment schlicht die Ressourcen. Es gibt aber interessaante Diskussionen im Internet. Ich empfehle den folgenden Beitrag

http://makarevitch.org/rant/raid/

Siehe auch die dortigen Links mit wirklich interessanten Statements und Erfahrungen zu 3ware-Controllern unter Linux. Hochinteressant finde ich vor allem die Vergleiche mit SW-Raid-Konfigurationen unter Linux, die mich ab und zu doch an meinen Investitionen in HW-Raid für Desktops zweifeln lassen.

Dennoch und aus dem Bauch heraus: Meine Erfahrungen sind im Mittel nicht schlecht, aber gerade mit laufenden VMware-Workstations wird der Platten I/O auf meine Opensuse Kisten bisweilen für kurze Momente zu einem echten, spürbaren Engpass. Zumindest, wenn man sich nicht ein wenig um die (begrenzten) Einstellmöglichkeiten des Controllers und auch des Linux-Systems kümmert.

Aufgefallen ist mir in der Praxis auch, dass auf meinen Opensuse-Systemen mit Quadcore-Prozessoren unter Last irgendwie immer (oder vor allem) der erste Core hohe WAIT I/O-Werte aufweist. Ich gehe mal davon aus, dass die 3ware-Treiber in Kombination mit dem Kernel den Controllerzugriff und den Datentransfer über genau einen Core handhaben. Auch dazu gibt es Hinweise in einschlägigen Diskussionen im Internet.

Der von mir auf den Desktop-Systemen verwendete Controller “9650SE-4LPML” ist ferner nicht ein System, bei dem man die Performance über große Raid-Stapel mit 12 oder 24 Platten hochziehen könnte. Mit 4 Platten sind die Möglichkeiten halt begrenzt.

Also fängt man an, ein wenig herumzuprobieren und vor ein paar Monaten habe ich tatsächlich mal ein wenig Zeit investiert, um mir mit “Bonnie++” verschiedene Konfigurationen anzusehen. Allerdings nur mit EXT3/Ext4 als Filesystem. Wenn ich auf dieser Basis Empfehlungen geben sollte, dann wären es folgende:

1) 4 Platten - Raid 10

2) Wenn man es sich leisten kann : Eher kein LVM einsetzen.

3) Controller-Parameter: Read-Cache auf “Intelligent” setzen und Write-Cache aktivieren (Battery Unit zur Vermeidung von Datenverlusten/Inkonsistenzen einkalkulieren). StorSave auf “Balance” oder “Performance” setzen. Verwendung von “Queuing” (NTQ Feature der Platten, wenn vorhanden) anschalten.
(Zum Einstellen von Controller-Eigenschaften kann man übrigens gut das übersichtliche “3DM2″ benutzen.)

4) Linux-Einstellungen - z.B. für ein Raid-Device, das unter “/dev/sda” anzusprechen ist:

echo “512″ > /sys/block/sda/queue/nr_requests

und danach (!):

blockdev   −−setra 16384 /dev/sda

5) VMware-Workstation (konfiguriert für 2 CPU-Cores eines Quad-Core-Systems):
Zuweisung des “vmware-vmx”-Prozesses an zwei andere Prozessor-Cores als den ersten, auf dem zumeist der I/O kontrolliert wird. Also z.B.:

taskset -pc 2,3 <pid des vmware-vmx-Prozesses>

Testet man die Performance unter diesen Bedingungen etwa mit zwei Raid 1 Units, die bei mir unter Linux als “/dev/sda” und “/dev/sdb” erscheinen, so erhält man mit Bonnie++ recht gute Werte für sequentielles Lesen und Schreiben (ca. 10% unter den theroretischen Maximalwerten der Platten). Aber es lohnt sich, auch andere Parameter-Werte - vor allem für blockdev - unter Linux auszuprobieren. Hier konnte ich durchaus messbare Unterschiede feststellen. Hat man gute Werte gefunden, hinterlegt man sich die Einstellungen in einem kleine Startup-Script. Der Wechsel auf Raid 10 führt dann nochmals zu einer signifikanten Steigerung der I/O-Werte.

Mit unterschiedlichen Schedulern habe ich auch rumgespielt. Irgendwie erschienen mir die Unterschiede aber nicht so signifikant zu sein.

Ich hoffe, ein paar von den Hinweisen helfen auch anderen weiter.

Geschrieben in Hardware, Treiber, Erfahrungsberichte, VMware Workstation | Keine Kommentare »

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 »