Ksymoops

Aus TuxBoxWIKI
Version vom 18. Januar 2010, 16:48 Uhr von Seife (Diskussion | Beiträge) (Die Seite wurde neu angelegt: = Kernel-Oops analysieren mit "ksymoops" = == Wozu das Ganze? == Der, auf der dbox2 meistens verwendete, Linux-Kernel 2.4 gibt im Falle eines schwerwiegenden Fehlers of...)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Kernel-Oops analysieren mit "ksymoops"

Wozu das Ganze?

Der, auf der dbox2 meistens verwendete, Linux-Kernel 2.4 gibt im Falle eines schwerwiegenden Fehlers oftmals eine so genannte "Oops-Message" auf der Konsole aus. Diese enthält Informationen über den Zustand des Kernels zur Zeit des Fehlers, insbesondere einen Stacktrace der zeigt, welche Funktionen zuvor aufgerufen wurden. Dieser liegt allerdings in einer Form vor, die nicht direkt lesbar ist und muss deswegen dekodiert werden.

Diese Dekodierung erfolgt mit dem Programm "ksymoops".

Achtung: ksymoops und die binutils müssen so gebaut sein, dass sie das Debuggen von PowerPC-Binaries ermöglichen. Das ist z.B. bei den auf openSUSE installierten ksymoops-Versionen der Fall. Ob die Architektur supported ist, kann mittels

ksymoops -a '?'

geprüft werden.

Vorbereitung

Zum korrekten Dekodieren werden einige Informationen ausser der Oops-Message benötigt. Diese sollten vorher schon mal gesammelt werden.

Der Inhalt der folgenden Dateien sollte vorher von der Box geholt werden:

  • /proc/ksyms - mit denselben Modulen (in derselben Reihenfolge!) geladen, wie zum Zeitpunkt des Oops
  • /proc/modules - ebenso mit allen Modulen geladen
  • die System.map, die zum laufenden Kernel passt. Typischerweise liegt die in cdk/linux/System.map. Achtung, wenn ihr erst ein Image gebaut habt, und danach ein Yadd, und das image crashed, dann wird die System.map dort für das Yadd sein, nicht für's Image
  • die vmlinux, dafür gilt dasselbe wie für System.map
  • Das Verzeichnis mit Kernelmodulen für den laufenden Kernel, typischerweise nach dem bauen im cdkroot in cdkflash/root-squashfs/lib/modules (für Flashimage) oder in cdkroot/lib/modules (für Yadd), alternativ direkt von der Box holen.

Diese Daten alle vorab einsammeln, z.B. (auf der Box) mit

cat /proc/ksyms > /tmp/ksyms
cat /proc/modules > /tmp/modules

Und dann per ftp in ein Verzeichnis auf den PC kopieren. In dasselbe Verzeichnis die System.map und vmlinux kopieren.

Den Oops "einfangen"

Wenn die box gecrashed ist, ist es am einfachsten (so sie denn noch läuft), den Oops wie folgt in eine Datei zu leiten:

dmesg > /tmp/oops.txt

Darin sollte dann so etwas stehen (Beispiel):

Oops: Kernel Mode Software FPU Emulation, sig: 8
NIP: C002B5D4 XER: 00000000 LR: C0029AFC SP: C0879DE0 REGS: c0879d30 TRAP: 1000    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0878000[219] 'neutrino' Last syscall: 4 
last math 00000000 last altivec 00000000
GPR00: C01B2948 C0879DE0 C0878000 C01B2934 00001032 00000000 C01E01B8 00000080 
GPR08: C002B5D4 00000002 00008049 C01B294C 00000000 101A68B4 C0879E90 C0160000 
GPR16: C0160000 C0879DEC C0140000 00000007 C0140000 0000003C 00000C5E C0140000 
GPR24: 000001D2 0000000E 000001FE C013C970 C01B294C C01B2950 00000000 C01B2934 
Call backtrace: 
C0029B38 C002AE00 C00247EC C0024E18 C0032C28 C000289C 0FCB5604 
1011B2B4 0FCAFA1C 0F955404 

Diese Datei wieder per ftp in das Verzeichnis auf dem PC kopieren.

Den Oops dekodieren

Das ist nun relativ einfach: in das Verzeichnis wechseln, wo alle gesammelten Informationen liegen und mittels

ksymoops -v vmlinux -k ksyms -m System.map -l modules \
         -o /dbox2/cdkflash/root-squashfs/lib/modules/ \
         < oops.txt > oops-decoded.txt

Danach sollte in oops-decoded.txt der dekodierte Oops zu finden sein.