Kernel-OOPS

Beitrag von jw » Mittwoch 5. Oktober 2005, 07:38

Hallo!

Kann mir jemand helfen mit folgendem Auszug die Ursache einzugrenzen?

Machine check in kernel mode.
Caused by (from SRR1=1032): Transfer error ack signal
Oops: machine check, sig: 7
NIP: C38BA0B8 XER: 00000000 LR: C38BA088 SP: C012FDD0 REGS: c012fd20 TRAP: 0200d
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c012e050[0] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000003 C012FDD0 C012E050 00000000 000003B0 000000E4 84352534 C014E1D0
GPR08: C0156840 C38C2000 C38C0000 C38C2000 04353533 1002051C 01FFBE00 00000001
GPR16: C0150000 007FFF00 C0150000 00000000 00001032 0012FF20 00000000 C0150000
GPR24: C012FE18 C0150000 C0110000 C0150000 000003B0 00000000 C38BC918 C1EE6B60
Call backtrace:
00000001 C38BC98C C0016994 C0014698 C0014520 C00141F4 C0004024
C00027C0 C0003F40 C0003F5C C0002258 C013F56C C0002138
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 <0>Rebooting in 180 seconds..

Das ist eine Sagem 1xI mit avia600.

Beitrag von **Npq** » Mittwoch 5. Oktober 2005, 08:57

Ich kenne deine Kernelsymbole nicht (die Adressen ändern sich bei jeder Kompilierung), aber anhand des Transfer Ack-Errors tippe ich mal wieder auf den Interrupthandler vom Avia.

Ich kann dir aber nicht sagen woher das kommt, speziell im Zusammenhang mit den Watchdogs ist mir aber schon mal aufgefallen, daß bei sehr vielen Interrupts scheinbar die Wahrscheinlichkeit eines Übertragungsfehlers steigt. Bin mir allerdings nichtmal sicher, ob das nun ein Hard- oder Softwareproblem ist.

Vermutlich müßte man tatsächlich die Kommunikation auf dem Bus loggen (mit einem Logikanalyzer), um dem auf die Schliche zu kommen.

Beitrag von jw » Mittwoch 5. Oktober 2005, 17:57

Npq hat geschrieben:Ich kenne deine Kernelsymbole nicht (die Adressen ändern sich bei jeder Kompilierung),

Auch wenn sich am source, an den compiler-flags und an den configure-optionen nichts aendert? Args! Das heisst doch fuer mich im Umkehrschluss, dass man die System.map (da stehen die doch drinne?) mit ins image aufnehmen sollte, wenn man eine realistische Chance haben will kernel/treiber-Problemen auf den Grund zu gehen?

aber anhand des Transfer Ack-Errors tippe ich mal wieder auf den Interrupthandler vom Avia.

Ich kann dir aber nicht sagen woher das kommt, speziell im Zusammenhang mit den Watchdogs ist mir aber schon mal aufgefallen, daß bei sehr vielen Interrupts scheinbar die Wahrscheinlichkeit eines Übertragungsfehlers steigt. Bin mir allerdings nichtmal sicher, ob das nun ein Hard- oder Softwareproblem ist.

Welche Watchdogs meinst du in diesem Zusammenhang? Doch wohl nicht den Watchdog, der in der CPU eingebaut ist? Und was meinst du mit "sehr vielen Interrupts"? AVIA-Interrupts? Oder allgemein hohe interrupt-Last? Letzteres war in diesem Fall vermutlich der Fall: Der OOPS ist passiert waehrend ein TS-Stream ueber Netzwerk abgespielt wurde.

Vermutlich müßte man tatsächlich die Kommunikation auf dem Bus loggen (mit einem Logikanalyzer), um dem auf die Schliche zu kommen.

Args. Solches Equipment habe ich natuerlich nicht zur Hand

Beitrag von **Npq** » Mittwoch 5. Oktober 2005, 21:56

jw hat geschrieben: Auch wenn sich am source, an den compiler-flags und an den configure-optionen nichts aendert?

Gut, ich habe mich unklar ausgedrückt. Wenn man nur neu kompiliert ohne den Code oder irgendwelche Compiler-Optionen anzufassen, sollten sie sich *theoretisch* nicht ändern. Aber meist kompiliert man ja nicht zum Spaß neu.

Für das Auflösen der Symbole gibt es ksymoops. Ist allerdings nicht im CVS, es gibt aber bei Debian ein PowerPC-Binary davon, das läuft auch auf der Box.

Die System.map kann man natürlich auch nehmen. Oder direkt das Modul disassemblieren.

Wenn man den 2.6er Kernel nimmt, kann man die Debugsymbole auch gleich einkompilieren und der schmeißt die einem beim Oops direkt raus. Superpraktisch irgendwie.

Welche Watchdogs meinst du in diesem Zusammenhang? Doch wohl nicht den Watchdog, der in der CPU eingebaut ist? Und was meinst du mit "sehr vielen Interrupts"? AVIA-Interrupts? Oder allgemein hohe interrupt-Last?

Nein, die beiden Watchdogs, die derget mal vor einem Jahr eingebaut hat, um Avia und Demux zu überwachen.

Er hat das beim Avia so realisiert, daß jedes dekodierte Audio- und Videoframe einen Interrupt (Avia zu CPU) auslöste. Davon kommen aber nun doch einige zusammen. Die genaue Zahl habe ich allerdings nicht mehr im Kopf.

Das waren aber mehr oder weniger Vermutungen, genauer verfolgt hatte ich das nicht.

Beitrag von jw » Mittwoch 5. Oktober 2005, 22:38

Npq hat geschrieben:Für das Auflösen der Symbole gibt es ksymoops. Ist allerdings nicht im CVS, es gibt aber bei Debian ein PowerPC-Binary davon, das läuft auch auf der Box.

OK, da werd ich mich mal auf die Suche machen...

Wenn man den 2.6er Kernel nimmt, kann man die Debugsymbole auch gleich einkompilieren und der schmeißt die einem beim Oops direkt raus. Superpraktisch irgendwie.

Warum ist 2.6 eigentlich nicht der Default?

Nein, die beiden Watchdogs, die derget mal vor einem Jahr eingebaut hat, um Avia und Demux zu überwachen.

Er hat das beim Avia so realisiert, daß jedes dekodierte Audio- und Videoframe einen Interrupt (Avia zu CPU) auslöste. Davon kommen aber nun doch einige zusammen. Die genaue Zahl habe ich allerdings nicht mehr im Kopf.

Vielleicht waere es mal einen Versuch wert, nicht bei jedem Frame sondern nur bei jedem X-ten Frame einen Interrupt auszuloesen? Nur so mal als Schnapsidee

Ich wuerde gerne mal einige Experimente in dieser Richtung tun. Leider finde ich auf die Schnelle keine naehere Infos zu diesem Thema. Hast du mal einen Hint, wo ich mehr Infos zu diesem Thema finden kann?