What Do These Kernel Panic Errors Mean

what do these kernel panic errors mean?

The values in parenthesis are the ifsr (instruction fault status) register. There are many causes for aborts and these give a specific cause. There are some tables in the kernel that handle particular fault causes and other have a handler which does a printk and aborts a task or can panic() the kernel. See: arm/mm/fault.c. The value is probably not valuable unless you are developing a fault handler. Although it can give an idea of what the fault is about, it is better just to get the PC and look at the code at that address (which I think was already printed?).

These faults can occur anywhere; in a user task, a kernel task or an interrupt handler, etc. Since your interrupt handler has crashed, Linux decides to stop everything and not bother proceeding. Otherwise, you could corrupts disks (even more), etc.

Note: Each fault status register has an abort.S file which is different for the particular ARM CPU. For example see abort-ev7.S v7_early_abort. This is put in a processor table which is matched at boot time.

1. Unhandled fault - trying to read memory that is not mapped (via MMU).
2. Kernel panic - an unhandled fault occurred in code deemed un-recoverable.

How to interpret kernel panics?

Since the error is in kmalloc (topmost line in the backtrace) it probably means that the memory allocator is failing. Common causes include double free()ing memory or otherwise corrupting the memory allocator structures.

Since the previous frames in the backtrace all belong to the module g_serial, I may suspect that's the culprit.

I'd suggest getting the debugging symbols for the kernel and modules so that you should be able to have the source code files and lines displayed in the backtrace. That will help a lot.

What do these Linux Kernel Oops fields mean?

Yes, EAX, etc. are 32-bit x86 processor registers. pdpt (page directory pointer table), pde (page directory entry), and pte (page table entry) are all paging structures.

IP (also EIP for 32-bit or RIP for 64-bit processors) is the instruction pointer at the time of the Oops.

The stack is the raw stack for this processor. Each processor will have its own stack. Note that on this architecture the stack grows down (addresses start with 0xfxxxxxx).

How to read, understand, analyze, and debug a Linux kernel panic?

It's just an ordinary backtrace, those functions are called in reverse order (first one called was called by the previous one and so on):

unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150

The bdi_register+0xec/0x150 is the symbol + the offset/length there's more information about that in Understanding a Kernel Oops and how you can debug a kernel oops. Also there's this excellent tutorial on Debugging the Kernel

Note: as suggested below by Eugene, you may want to try addr2line first, it still needs an image with debugging symbols though, for example

addr2line -e vmlinux_with_debug_info 0019594c(+offset)

---

Related Topics