ksymoops reads the stack trace and code fragment straight from input,
in the order they are printed. So it really depends on
arch/xxx/kernel/traps.c. For ix86, stack is latest first, code is
printed from the EIP onwards. Just to confuse the issue, some other
architectures print code either side of EIP, some even print code bytes
in words which have to be byte swapped to make any sense (see the -c
option in ksymoops/README).
>I'm still not clear on what the numbers next to the function name are, I
>assumed they were line numbers... but I checked the source and they
>don't seem to corrispond.
First figure is offset within proc, second is length of proc. By
default they are in hex but, because both gdb and klogd use decimal,
ksymoops has a -x toggle to switch between hex and decimal
offsets/lengths.
>Typically, given the above kernel oops, how would one go about finding
>the bug. Open up each function in the trace and see if there are any
>blatently obvious problems and if not stick a printk() in it and wait
>for an oops?
Deduction. From the Oops decide which register is at fault. Use gdb
to dissassemble the proc, see how that register got loaded. Work out
which structure or passed variable is incorrect. Then try to find out
how the bad value was created in the first place. The last step is the
hardest.
>Are there any good books on debugging the Linux kernel. With an average
>program it's easy, wait for a seg fault or insert some breakpoints
>something is goign wrong, and run the program then get a backtrace with
>complete pointers to the source including line numbers and function
>arguments.
You can get something like that with the Integrated Kernel Debugging
patch, ftp://e-mind.com/pub/linux/patch-ikd-arca, current is
patch-ikd-arca-2.2.5.bz2.
>Do any other Unices have any more advanced crash analysis techniques?
>I've read something about a kernel core file for some OS's.
The question of taking a kernel core dump has been been raised before
on Linux. The big stumbling block has always been "can we trust the
I/O layer after an Oops?". If the fault affects disk I/O then writing
to a kernel core file could easily corrupt your entire disk. AFAIK,
nobody has though the benefit worth the risk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/