linux-l: Kernel OOPS

[Dr. Guido Seifert]

> > 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. 

Das tut er bei mir auch. Ich habe den Output selbstverstaendlich durch
ksymoops geschickt. Das Ergebnis ist fuer mich trotzdem sehr unverstaendlich.
Ich hatte hier nur die Kurzfassung geschickt, da solch lange Dumps fuer die 
meisten hier doch recht laestig sein duerften.

> > 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.

Da hast auch in diesem Fall recht, aber das ist keine Loesung fuer jemanden, 
der Linux beruflich einstetzt. Wenn der Fehler in meinen Programmen auftreten
wuerde, wuerde ich das selbstverstaendlich so (oder so aehnlich) machen,
aber ich habe nicht die Zeit, den Kernel oder dessen Module zu debuggen.

> Dafuer gibt es ja ksymoops und infos dazu unter
> /usr/src/linux/Documentation/oops-tracing.txt.
> 
> Meistens muss man leider nach dem oops rebooten, da der rechner komplett tot
> ist. Da hilft dann eigentlich nur den oops ueber die serielle-console
> mitzuloggen....

Es ist zwar komplett tot, aber zumindest noch so freundlich seine 
Todesmeldungen in /var/log/messages zu verewigen.


> Den ksymoops output kann man dann auch auf die kernel-mailinglist posten,
> vorausgesetzt, man liefert eine genaue Beschreibung, hat die neueste Version
> probiert usw. 

Geht leider  nicht. Auf dem entsprechenden Rechner laeuft 2.2.14 und ich habe
nicht die Berechtigung auf 2.2.17 upzugraden. Und ich moechte die Mailinglisten
nicht uralt-Kernelbugs flooden :-)

> Allerdings ist mit einem schnellen Bugfix nur zu rechnen, wenn
> du direkt an den Schuldner (und es ist nicht leicht zu wissen wer schuld
> ist...) mailst!
> 
> > 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.

Ok, _damit_ bin ich zur Zeit allerdings wirklich ueberfordert. Wenn ich das so
eingfach koennte, wie Du es hier beschreibst, waere mein Gehalt vermutlich 
noch um eine Groessenordnung hoeher ;-)
 
> Und mit nem Kernel Patch kannst du sogar ueber die serielle von nem anderen
> Rechner aus debuggen und den kernel anhalten und durchtracen... Ziemlich
> cool.

 
Aber inzwischen hat sich das Problem sowieso mehr oder weniger erledigt.
Ich habe ein quasi identische Fehlermeldung unter:

http://kt.linuxcare.com/kernel-traffic/kt19991213_46.epl

 (Google Bug Hunt)

gefunden. Es sieht sehr nach einem Hardwarefehler aus.


Gruss
Guido