Fehler/Kernel

aus openSUSE, der freien Wissensdatenbank

Auf dieser Seite wird beschrieben, wie man Fehler im Kernel finden und melden kann.

Einführung in die Fehlersuche im Linux-Kernel

Dieses Dokument befindet sich in einem laufenden Entwicklungsprozess. Es ist dazu gedacht, dabei zu helfen, dass Auffinden und Beheben von Kernelfehlern zu vereinfachen und für all die Menschen, die an diesem Prozess beteiligt sind.

• Unterstützer und Berater die wissen, wie man einen nützlichen und wertvollen Fehlerbericht schreibt.
• Entwickler, die wissen müssen, wie man Einrichtungen des Kernels überprüft.

Eine Einordnung der Kernelfehler

Fehler im Kernel lassen sich nach unterschiedlichen Schemata sortieren (bspw. nach ihrer Wirkung auf die Sicherheit oder die Datenintegrität). Da es hier um die Fehlerjagd geht wollen wir versuchen, sie nach ihrer Komplexität zu sortieren.

• Arbeitet nicht wie erwartet
  Manche Fehler im Kernel lassen sich einfach lokalisieren und reproduzieren und haben keinen Einfluss auf die Stabilität des Restsystems. So könnte eine Netzwerkkarte bei bestimmten Konfigurationen nicht funktionieren oder NFS produziert einen Haufen sonderbarer Fehler.
  Solche Dinge sind oft recht einfach zu finden und zu beheben. Alles was man dazu braucht ist eine präzise Beschreibung dessen, was passiert und wie es sich reproduzieren lässt. Und natürlich noch einen Kernel-Hacker der sich im entsprechenden Untersystem gut auskennt. :)

• Kernel Oopses
  Sobald der Kernel in eine unerwartete Fehlerlage gerät (bspw. beim Rückverweis durch einen ungültigen Zeiger), fängt eine Fehlerbearbeitung den Fehler ab und versucht, den Fehler möglichst detailliert zu protokollieren. Normalerweise wird diese oops-Nachricht ins Systemprotokoll geschrieben; es ist allerdings auch möglich, die Nachricht auf einer Textkonsole anzuzeigen, was allerdings standardmäßig deaktiviert ist und manuell aktiviert werden muss.
  Da diese Nachricht mit den Worten "Kernel Ooops" startet, wird das ganze Ereignis als "oopsing" bezeichnet.
  Wenn ein oops auftritt, befand sich der verursachende Prozess meist mitten in einer wichtigen Tätigkeit innerhalb des Kernels und hielt eine oder mehrere Sperren (locks). Da der Prozess sofort terminiert wird, wird keine dieser Sperren wieder gelöst, so dass Prozesse, die später versuchen, diese Sperren für sich zu beanspruchen, hängen bleiben.
  Wenn sich der Nutzer in einer X-Sitzung befindet, bspw. mit KDE oder GNOME, erscheint es ihm, als sei der Rechner komplett hängen geblieben, da der X-Server an einigen toten Kernelsperren festhängt und nicht mehr reagiert.

• Kernel Panics
  Falls ein oops innerhalb einer Interrupt-Verarbeitung auftritt, wird der Kernel versuchen, die oops-Nachricht zuzustellen und danach komplett anhalten, da es keinen Weg gibt, die Arbeit nach dem Absturz einer Interrupt-Verarbeitung fortzusetzen. Dies wird als Kernel Panic bezeichnet.
  Im Fall einer Kernel Panic werden die oops nicht in Syslog geschrieben; ganz einfach deshalb, weil der Syslog-Daemon nicht mehr betriebsfähig ist.

• Soft Lockups
  Einige Kernel-Fehler lösen keine oopses aus, sondern sorgen einfach nur dafür, dass das System einfriert. Sie können von deadlock oder livelocks zusammen mit anderen Dingen ausgelöst werden. In den meisten Fällen (außer einige dumme Fehler bringen den Interrupt-Verarbeiter dazu, an einer Sperre abzudrehen) unterbinden diese Soft Lockups nicht die Zustellung von Interrupts.
  So lange die Interrupt-Zustellung noch möglich ist, wird das System noch auf anpingen reagieren und Tastatureingaben werden auf der Textkonsole ausgegeben. Trotzdem werden die laufenden Prozesse keinen Fortschritt mehr machen.
  Im Grunde wird das System unempfänglich sein, da die Prozesse nicht mehr weiterlaufen.
  Ein guter Weg um dies zu testen, besteht in der Betätigung der Feststell- oder der Ziffernblocktaste. Wenn die LED-Anzeigen der Tastatur für diese Tasten noch funktionieren, dann haben Sie irgendwo ein deadlock.
  Kernel der 2.4er Serie fangen in so einem Fall an, die Ziffernblock-LED (Num) blinken zu lassen, falls sie sich aufgehängt haben. 2.6er Kernel verfügen bisher noch nicht über diese Funktion.

• Hard Lockups
  Genau so gut kann auch ein Hard Lockup auftreten; diese werden meist durch Hardwareprobleme ausgelöst (oder durch exzessiven Missbrauch der Hardware durch schlecht geschriebene Treiber). Falls dies passiert haben Sie ein echtes Problem. Sie können dann mit dem Lesen hier aufhören und wir wünschen ihnen viel Glück bei der Fehleranalyse.

Die richtigen Informationen zusammentragen

Nutzer tendieren oft dazu, bei Softwareproblemen dem aus ihrer Sicht komplexesten und mysteriösesten Teil des Systems die Schuld zu geben. Dies ist dann in den meisten Fällen der Kernel.

Das meint nicht, dass sie damit unbedingt falsch liegen müssen. Aber es meint oft, dass ihre Fehlerberichte ungenau sind oder wichtige Details vermissen lassen.

Wenn Sie also damit beauftragt wurden, einen Linux-Kernel-Fehler zu analysieren (oder das, was jemand für einen Linux-Kernel-Fehler hält), dann gibt es ein par Fragen zu den Symptomen, die Sie zuerst stellen sollten:

• Hänger kontra Absturz
  Hängt das System? Ist es abgestürzt? Erscheint es nur so, als sei es abgestürzt?
  Sogar erfahrene Nutzer werden nicht immer daran denken, dass Systemprotokoll auf oops-Nachrichten zu kontrollieren, speziell wenn sich der Kernel "nur reichlich ungewöhnlich" verhält, aber noch nicht spektakulär in Flammen aufgegangen ist. Sie können sich selbst eine Menge Arbeit ersparen, wenn Sie sie fragen, ob sie ihre Systemprotokolle trotzdem auf oops-Nachrichten geprüft haben.
  Wie schon weiter oben geschrieben, erscheint es dem Nutzer beim Auftreten eines Kernel Oops und der Verwendung von X oft so, als hätte sich die Maschine aufgehängt.
  Bei 2.4er Kerneln gibt es einen Effekt der darauf hinweist, dass ihr Kernel in Panik verfallen ist, sogar wenn Sie sich in X befinden: die LED des Ziffernblocks ihrer Tastatur beginnt zu blinken. 2.6er Kernel haben diese Fähigkeit bisher noch nicht.
  In diesem Fall hilft es immer, das Problem nach einem Wechsel in die Textkonsole zu reproduzieren. Falls sich das System nicht hart aufgehängt hat wird der Kernel zumindest noch Tastatureingaben akzeptieren. Auf der Konsole ist es auch möglich, zusätzliche Informationen über den Absturz zu sammeln. Als Minimum sollten Sie dem Kernel vorgeben, die oops-Nachrichten auch auf der Konsole auszugeben, nutzen Sie dafür
  

# klogconsole -r0 -l8

Falls der oops nicht ins Systemprotokoll geschrieben wird (bspw. weil der oops innerhalb eines Interrupts aufgetreten ist), kann es auch helfen, die Ausgabe mit einer Digitalkamera abzufotografieren (stellen Sie aber bitte sicher, dass der Anhang eines Fehlerberichts 512KB nicht übersteigt).
Alternativ kann auch versucht werden, den oops über eine serielle Konsole einzufangen.
Zusätzlich möchten Sie vielleicht sysrq aktivieren und einige sysrq-Informationen abgreifen, wie es im Abschnitt sysrq nutzen weiter unten beschrieben wird.

• Schließen Sie altbekannte Probleme aus
  Dies sind verschiedene Arten von Problemen die so weit verbreitet sind wie Schmutz. Seien Sie sich dieser Probleme bewusst und versuchen Sie, diese frühzeitig auszuschließen.

Nummer eins auf der Liste nerviger Probleme ist sicherlich ACPI:

Wenn ein Nutzer von Problemen beim Booten oder von nicht korrekt eingerichteter Hardware berichtet, dann sind meistens schlechte ACPI-BIOS-Tabellen schuld.

Versuchen Sie, mit acpi=off zu booten, um ACPI komplett zu deaktivieren.

[Liste von auf ACPI bezogenen Kernel-Kommandozeilenvariablen]

Andere weit verbreitete Probleme?

• Schließen Sie unwichtige Variablen aus
  Nutzer beschreiben in ihren Fehlerberichten oft ziemlich spezifische Szenarien, wie "Ich exportiere meinen USB-Stick mit ReiserFS als Dateisystem und exportiere ihn über NFS während ich MP3s höre und dann stürzt die ganze Maschine plötzlich ab".
  Dies ist ein hübscher und akkurater Bericht, der fast jedes Subsystem des Kernels umfasst (Block-Geräteschicht, VM, VFS, Netzwerk, Audio, ...)
  Um ihnen dabei zu helfen, das Problem einzugrenzen sind hier einige Dinge, die Sie tun können:
  • Besteht das Problem auch mit älteren/neueren Kernel-Versionen?
  • Wenn Sie eine der genannten Aktionen nicht ausführen, kann der Fehler dann immer noch reproduziert werden?
  • Wenn Sie eine Komponenten gegen eine andere, gleichwertige austauschen (bspw. ReiserFS durch Ext3 ersetzen), tritt das Problem dann immer noch auf?
  • Falls das Problem Arbeitsspeicherfehler oder zufällige Hardware-Fehler impliziert: Kann das Problem auf einer anderen Maschine reproduziert werden?
  • Gerade auf großen Maschinen können zufällige Arbeitsspeicherfehler durch Hardware-Probleme mit schlechtem RAM ausgelöst werden. Um herauszufinden, ob in ihrem Gerät schlechter Arbeitsspeicher verbaut ist, verwenden Sie die Installations-CD, wählen Sie dort den Speichertest memtest86 und lassen Sie ihn 24 Stunden lang laufen.

Oops-Infos erfassen

Wie zuvor schon beschrieben wurde, resultiert ein Kernel-Absturz in einem Oops, welcher in die Systemprotokolle geschrieben wird. Die oops-Nachrichten enthalten einen großen Anteil an Informationen, die ihnen dabei helfen können, dass eigentliche Problem herauszufinden.

In (relativ) freundlichen Fällen wird der Kernel trotz der Fehlersituation in der Lagen sein weiterzulaufen und das System wird stabil genug sein, um zumindest noch die oops ins Systemprotokoll einzutragen. Falls der Kernel in Panik ausbricht ist es allerdings absolut nicht mehr einfach, ein oops aufzuzeichnen.

Ihr größter Feind ist dabei die Arbeitsfläche. Jede Kernel-Meldung die in die Konsole geschrieben wird, während der X-Server läuft, wird nicht auf dem Bildschirm angezeigt. Der X-Server verfügt über Mittel, Nachrichten, die in /dev/console geschrieben werden, abzufangen, aber wenn der Fehler schwerwiegend genug ist, um syslogd und klogd davon abzuhalten, den oops ins Systemprotokoll zu schreiben, stehen die Chancen für X zur Zeit sehr schlecht, ihnen irgendeine nützliche Information anzuzeigen.

Wenn es ihnen also irgend möglich ist, das Problem zu reproduzieren, sollte ihr erste Schritt darin bestehen, auf eine Textkonsole zu wechseln und sich die Konsolenprotokollierung anzuschauen:

klogconsole -r0 -l8

Dies ändert den Protokollierungsgrad der Kernel-Konsol auf alles was er auch an die virtuelle Konsole sendet. Dies beinhaltet alle Kernel oopse; wenn Sie nun den Kernel-Fehler auslösen erhalten Sie einen Bildschirm voller opps-Informationen.

Hinweis: Wenn Sie dies regelmäßig machen, dann schauen Sie sich bitte den Abschnitt zur seriellen Konsole weiter unten an - dies ist dabei die absolut bevorzugte Methode, allerdings ist es auch schon ein großer Gewinn, die oops überhaupt schon mal lesen zu können. Um zu lernen, wie Sie oops lesen können, halten Sie sich bitte an die Datei oops-reading.

ksymoops nutzen

Ein Kernel oops enthält für gewöhnlich ein Abbild des aktuellen Prozessorzustands, samt Registerinhalten, den Instruktionszeigern und einer Rückverfolgung von Funktionsaufrufen. Damit diese Informationen für die Kernel-Entwickler von Nutzen sind, müssen diese Adressen, soweit möglich, auf Funktionen und/oder Variablennamen abgebildet werden.

Aktuelle openSUSE-Kernel unterstützen eine Funktion namens "kallsysms", durch die der laufende Kernel eine Symboltabelle von sich selbst mitführt, welche es erlaubt, Adressen automatisch aufzulösen wenn ein oops geschrieben wird.

Ältere Kernel verfügen nicht über diese Funktion, so dass die geschriebenen oops die Rohadressen enthalten, welche dann noch Anwendungen aus dem Nutzerraum (user space) zugeordnet werden müssen.

Genau dafür ist ksymoops da: Sie können ksymoops über die Standardeingabe mit Roh-oops füttern, und wenn ihm die richtigen Symbolinformationen gegeben sind, wird es Sie mir einer aufbereiteten Version des oops versorgen, die alle Symbole und eine Disassemblierungsliste der hex-Instruktionen abbildet.

Die Crux bei der ganzen Sache besteht allerdings darin, ksymoops mit den richtigen Symbolinformationen zu versorgen. Diese Informationen werden normalerweise dem vmlinux-Abbild und der System.map-Datei in /boot entnommen, welche exakt zur Version des Kernels passen müssen, der die oops generiert. Deshalb ist es immer eine gute Idee, ksymoops auf der Maschine auszuführen, auf der der Absturz aufgetreten ist.

Wenn es darum geht, Modulsymbole korrekt aufzulösen, benötigt ksymoops eine Liste der Kernel-Module und ihre Positionen im Arbeitsspeicher. Ein guter Weg, diese Informationen zu erhalten ist, sofort vor oder nach dem Auftreten eines oops die Datei /proc/modules zu kopieren, und diese Kopie dann ksymoops beim Aufruf mit der -l Option mitzuteilen:

# ksymoops -l /tmp/proc-modules-Kopie < /tmp/meine-oops

Glücklicherweise wird ein Großteil dieser Arbeit bereits automatisch erledigt wenn der oops vom syslogd eingefangen wird, da syslogd all die Symbolübersetzungen für Sie erledigt. Dies hat den großen Vorteil, dass immer die korrekte Symbolliste verwendet wird.

Natürlich werden oopse, die über die serielle Konsole eingefangen werden, nicht ihre Adressen durch ksyslogd mitgeteilt bekommen, weshalb Sie in diesem Fall ksymoops manuell ausführen müssen.

sysrq nutzen

sysrq steht für "system request". Dies ist der Name für einen Haufen magischer Tastenkombinationen, die den Kernel anweisen, verschiedene Arten interner Informationen anzuzeigen, dass Dateisystem zu synchronisieren oder einen Prozess abzubrechen. Da diese Möglichkeiten auch die Sicherheit des Systems beeinträchtigen (bspw. das Abbrechen von Prozessen), sind sie sysrq-Tastenkommandos standardmäßig deaktiviert.

Ein Weg, sysrq zu aktivieren ist, das folgende Kommando in einer Sehll auszuführen:

echo 1 > /proc/sys/kernel/sysrq

Zusätzlich können Sie in der Datei /etc/sysconfig/sysctl die Variable ENABLE_SYSRQ verändern, durch die sich sysrq dauerhaft aktivieren lässt.

Um sysrg zu nutzen müssen Sie eine "magische" Tastenkombination und eine Kommandotaste drücken. Diese magische Tastenkombination hängt von der Hardware-Plattform ab, ist aber meistens Alt+SysRQ (auf einigen Tastaturen ist die SysRQ-Taste als "PrtSrc" oder "Druck" beschriftet, normalerweise befindet sie sich rechts von den Funktionstasten (F1 bis F12)).

Die meisten sysrq-Tasten veranlassen den Kernel, Statusinformationen auf die serielle Konsole auszugeben. In der Standardkonfiguration leitet eine openSUSE-Distribution alle vom Kernel generierten Ausgaben auf tty10 um, so dass Sie auf Konsole 10 umschalten müssen oder die Kernel-Konsole mit klogconsole auf eine andere tty umleiten müssen.

Die hilfreichste Kommandotaste ist "h", welche einen kurzen Hilfetext einblendet:

SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem powerOff showPc
		unRaw Sync showTasks Unmount

Es folgt eine Beschreibung der wichtigsten Kommandos:

0-8	Diese Tasten ändern den Konsolenprotokollierungsgrad auf die gewünschte Stufe.
        8 zeigt alles auf der Konsole an, 1 nur kritische Meldungen 
        und 0 schaltet die Konsolenprotokollierung komplett aus.
M	Zeigt die aktuelle Speicherstatistik an
P	Zeigt die aktuellen Prozessorregister, Instrunktionszähler, Aufrufverfolgungen
        und geladenen Module an. Dies sind im Wesentlichen die Informationen über Prozesse 
        die als Teil eines oops ausgegeben werden.
T	Zeigt eine Auflistung aller Aufträge, samt Rückverfolgung 
        ihres Kernelstapelspeichers an. Achtung, diese Liste kann sehr lang sein.
U	Versuche alle aktuell eingebundenen Dateisysteme im Nur-Lesen-Modus neu einzubinden.
E	Sende ein TERM-Signal an alle Prozesse bis auf init.
I	Sende ein KILL-Signal an alle Prozesse bis auf init.

Es gibt noch weitere sysrq-Taste; eine komplette Liste finden Sie in der Datei Documentation/sysrq.txt in den Kernel-Quellen.

Es ist ebenfalls möglich, sysrq-Kommandos von der Kommandozeile aus abzusetzen, was sehr nützlich ist, wenn Sie keinen Tastaturzugriff haben (bspw. wenn Sie ein Problem aus der Ferne analysieren). Setzen Sie in diesem Fall den gewünschten Buchstaben mit Hilfe von echo in /proc/sysrq-trigger ab und schauen Sie sich die ausgegebenen Informationen mit dmesg oder in den Systemprotokolldateien an:

# echo t > /proc/sysrq-trigger

Using lkcd

[TBD]

Using nmi_watchdog

[TBD]

Die serielle Konsole nutzen

Einige Kernel Oops können auftreten (besonders während des Boot-Vorgangs), wenn die Systemkonsole noch nicht nutzbar ist. Um in solch einem Fall einen verlässlichen Bericht zu erhalten, kann man die serielle Konsole zu Hilfe nehmen. Sie benötigen einen zweiten Rechner und ein Null-Modem-Kabel (bspw. ein serielles Kabel mit zwei identischen Anschlüssen); zusätzlich müssen beide Maschinen über einen seriellen Anschluss verfügen. Diese Voraussetzungen lassen einige moderne Maschinen außen vor, da diese nicht mehr über solche Anschlüsse verfügen, auf diesen müssen Sie es dann mit netconsole versuchen.

Nachdem Sie das Kabel angeschlossen haben sollten Sie der Kommandozeile des Debuggers 'console=ttyS0,115200 console=tty0' hinzufügen. Dies sorgt dafür, dass alle Konsolenmeldungen sowohl an ttyS0 als auch an die Standardkonsole gesendet werden. Der letzte console=-Parameter legt fest, von wo die Konsoleneingaben entgegengenommen werden sollen; wenn Sie also wollen, dass auch die serielle Konsole Eingaben entgegen nimmt, müssen Sie diese Parameter austauschen.

Auf der empfangenden Maschine müssen Sie nur screen (als root) mit dem folgenden Kommando starten:

# screen -T vt100 /dev/ttyS0 115200

(Davon ausgehend, dass die serielle Verbindung über den ersten Anschluss hergestellt wird). Führen Sie dann einen Neustart durch und schauen Sie zu.

Um oops einzufangen ist es am einfachsten, die Protokollierung von screen zu aktivieren; lesen Sie dazu das screen-Handbuch.

Autoren

Olaf Kirch <okir@suse.de>
Hannes Reinecke <hare@suse.de>

Was soll ich mit einem Kernel-OOPS machen?

Lesen Sie dazu das separate Dokument OOPS reading.

Wie kann ich ein Kernelproblem beheben?

Lesen Sie dazu das separate Dokument Kernel Debugging Introduction.