From: mdw@db.TC.Cornell.EDU (Matt Welsh) Subject: HOW TO TRACE KERNEL PANICS (was Re: HELP ME! Kernel panics!) Date: Wed, 17 Feb 1993 17:00:35 GMT
merlin@mits.mdata.fi (Markku M{kel{) writes:
>Unable to handle kernel paging request at address c0000000
>Oops: 0000
>EIP: ....
This is starting to be an FAQ, and I'm sorry I didn't get it into the most
recent FAQ posting. Here's info from Linus on how to track down the source
of kernel panic messages. The values for EIP, address, and so on are JUST
EXAMPLES: the EIP, EFLAGS, etc. can be anything.
The lines after ">" were written by me; the responses by Linus.
> Unable to handle kernel paging request at address C000000A
This means something in the kernel tried to access kernel memory at
address 0x00A (the C0000000 offset is due to the kernel starting at
virtual address 0xC0000000). The first page of kernel address space is
unmapped to find these kinds of incorrect references (it's probably a
NULL dereference to a structure member at offset 0xA).
> Oops: 0002
Error code. This tells you if it's a read or write (forget which ritgh
now, and don't have any books handy)
> EIP: 0008:000290D2
This is where it happened: segment 0008 (kernel code segment) and offset
0x290D2 into the kernel. So to find this, you generally do something
like
nm /usr/src/linux/tools/system | sort | less
and search for the function that contains the address 0x290D2.
> EFLAGS: 00010087
> fs: 0017
Eflags and fs when the exception happened. You usually don't need this.
> base: C0000000, limit: 000A0000
> Pid: 0, process nr: 0
In what process the exception happened. This is the swapper, which also
means the thing is fatal (other processes you can just kill). That it's
in the swapper process probably means that it's an interrupt that did
it, as the swapper doesn't really do anything.
> 89 50 04 c7 03 00 00 00 00 c7
This is the instruction that resulted in the error. I usually
disassemble them by hand and see what it is, then I try to find out
exactly where in the function this assembly sequence comes up (probably
by compiling the .c file to a .s file and looking around).
Alternatively you can just run 'gdb' on /usr/src/linux/tools/system, but
gdb has some problems.
> task[0] (swapper) killed: unable to recover
> kernel panic: Trying to free up swapper memory space
> In swapper task - not syncing
This is just to tell you not to expect anything from the kernel any
more: linux cannot go on without the swapper task.
> How can I decode the numbers in the message?
> Also, note that sometimes the "Unable to handle..."
> message is followed by the "Oops: 0002" block, but
> the last message is sometimes something else (i.e. not
> always a "task[0] (swapper)...." message, but something
> from the TCP driver in this case.
It depends on where it happened. If it's an interrupt, it can
essentially happen in any task (all interrupts are handled in the task
that happens to be currently active), while "normal" code happens in the
task that calls it.
mdw
-- Matt Welsh, mdw@tc.cornell.edu "What are you doing, Dave?"