linux-l: Kernel OOPS

[Stefan Bund]

"Dr. Guido Seifert" <seifert at living-net.de> writes:
> Hi, 
> kennt sich jemand genug mit Kernel OOPS aus, dass es sich lohnt, mal den
> entsprechenden Dump zu mailen?
> 
> Kurzfassung:
>   Unable to handle kernel paging request at virtual address 08000014
>   Unable to handle kernel NULL pointer dereference at virtual address 00000014
> 
> 
> Was sagt mir das? Im INet gibt es zwar dutzende Fragen zu solchen Fehlern,

Nicht viel :-) ... ich hatte sowas auch mal ziemlich ausführlich
(Fehler in einem Netzwerkkartentreiber). Bei mir hat er nicht nur die
Adresse sondern auch den namen der Funktion angegeben, in dem der
Fehler auftritt. Diese Namen werden mittels der system.map ermittelt,
da stehen die Anfangsadressen sämtlicher funktionen im Kernel
drin. Wenn man dann erst mal weiß, in welcher funktion das auftritt
(und vorausgesetzt, das Problem ist reproduzierbar) kann man einfach
in die Funktion ein paar `printk' befehler einbauen. Das hat bei mir
sehr gut geholfen. Der Fehler lag dann in einer der Funktionen
rückwärts im call-stack. Hat halt ein bischen gedauert, sich schritt
für schritt näher an das Problem ranzuarbeiten, aber ist prinzipiell
eigentlich kein Problem. 

Dazu sollte man natürlich etwas C beherrschen :-) ... ansonsten. Auf
jedenfall kannst du die Fehlermeldung (allerdings NUR mit aufgelösten
methodennamen) an die linux-kernel-bug oder andere entsprechende Liste
schicken (ich habe die adresse gerade nicht zur hand ... sollte aber
im Documentation verzeichniss des Linux Kernels stehen). Aber
natürlich erst mal den aktuellsten Kernel ausprobieren ... ob der
Fehler da behoben ist.

Ich finde die printk-Lösung äußerst praktikabel und einfach. Die
funktioniert auch dann, wenn man nicht so ganz genau versteht, was
eignetlich abläuft, meistens ist der Fehler ziemlich einfach (so war's
in den 2 fällen bei mir dedenfalls).

Man kann auch den Kernel mit debuginformation übersetzen und dann den
laufenden Kernel mit dem gdb debuggen (dazu gibt's /proc/kcore). Du
kannst natürlich keine Breakpoints setzen oder den Kernel anhalten
aber man kann sämtliche Datenstrukturen analysieren. Das hat mir aber
nicht viel gebracht.

Stefan.

PS: Hat sich eigentlich schon mal jemand darüber gedanken gemacht, den
Kernel mittels RT-Linux zu debuggen? Soweit ich weiß, läuft der Kernel
und RT-Linux als ein Thread und andere realtime-threads können den
Kernel unterbrechen. Ein kleines Benutzerinterface in einen
RealtimeThread packen (zum Beispiel anzusprechen über die serielle
Schnittstelle) ... und viola ... der Kernel lässt sich RICHTIG
debuggen (mit breakpoints und so).

Ist natürlich nicht so einfach aber gibt's da was? Bin ja nur
neugierig ...