How to understand the kernel panic core dump output?

Question

This is the output I get when I run one of my applications:

Kernel bug detected[#1]:
Cpu 0
$ 0   : 00000000 00000000 0fffff00 0fffff00
$ 4   : c6800000 850b7780 8b0043c0 00000040
$ 8   : 000004ac 000004ac 00000002 844e8000
$12   : 00000000 feced300 8430d2ac 0000000a
$16   : 00000040 000000fc 8b759300 00000001
$20   : 00000012 84370000 00000004 00000009
$24   : 00000000 8403d4f4                  
$28   : 8b1c0000 8b1c3ee0 0000000a 84255764
Hi    : 003d08ef
Lo    : 79432700
epc   : 840a754c 0x840a754c
    Tainted: P          
ra    : 84255764 0x84255764
Status: 1100dc03    KERNEL EXL IE 
Cause : 00800034
PrId  : 00019749 (MIPS 74Kc)
Modules linked in: em8xxxcursor(P) em8xxxfb em8xxxcopybit(P) pmem_rua em8xxx(P) llad(P)
Process events/0 (pid: 4, threadinfo=8b1c0000, task=8b0323d8, tls=00000000)
Stack : 8b0323d8 8402d074 843d0c68 843d10e8 8b1c3f80 8b0323d8 843d0cc8 8b2d6de8
        8b2d6de8 8402d194 00000003 00000000 00000000 84300000 84374104 8b124c80
        84255238 fffffffc efffffff 8431d16c 8431d1a4 00000000 00000000 8404c364
        8404cc6c 00000001 8b124c88 8b124c80 8b124c88 8b124c80 8b1c3f80 00000000
        00000000 00000000 00000000 8404cc04 8b03254c 8b03254c 84051638 00000000
        ...
Call Trace:[<8402d074>] 0x8402d074
[<8402d194>] 0x8402d194
[<84255238>] 0x84255238
[<8404c364>] 0x8404c364
[<8404cc6c>] 0x8404cc6c
[<8404cc04>] 0x8404cc04
[<84051638>] 0x84051638
[<84051b14>] 0x84051b14
[<8404cba8>] 0x8404cba8
[<84051650>] 0x84051650
[<8401504c>] 0x8401504c


Code: 3c030fff  3463ff00  00431024 <00028036> 09029cfd  24050001  27bdffc8  0085102b  afb7002c 
Kernel panic - not syncing: Fatal exception in interrupt

Am I able to get some info from this dump regarding the issue which is making this happen?

Solution

Core dumps are easier to read if you can associate them with a symbol table. That way a debugging tool can translate memory map addresses into mnemonics, i.e., data structures, function names, global variables and so on. The call trace above, for one, would be a lot more helpful.

For a panic-induced dump, the usual way to read a core dump is to track back from the failure to a likely cause. The most likely trail to follow is the process that was executing at the point of failure. In most kernels, with the appropriate debug symbol information available, you can then step back, instruction by instruction, to find a bad value.

I'm not familiar with the presentation of this output, but it looks like maybe your kernel received an interrupt in a state in which it asserted no interrupt should arrive. This kind of rule is a guard against computing on data when it doesn't appear to be safe to do so, so the kernel panics to guard against munging. Just a guess on my part, though.

A lot of kernels run with all symbol information stripped to get as light as they can. It looks like you'd have to compile these values into your kernel to get more easily digestible panic output.