Skip to contentSkip to conversation

Debug kernel panic with gdb?

DISCUSSION Arvid Brodin 2 participants 3 messages Mar 24, 2011 – Mar 25, 2011

lore
Share & tools
lore

Arvid Brodin

author
#0 lore raw

Hi,

I'm trying to debug a kernel panic (something like this):

Unable to handle kernel NULL pointer dereference at virtual address 00000014
ptbr = 93959000 pgd = 93a0a000
Oops: Kernel access of bad area, sig: 11 [#1]
FRAME_POINTER chip: 0x01f:0x1e82 rev 2
Modules linked in: ftdi_sio usbserial
PC is at isp1760_irq+0xda/0x7f0
LR is at isp1760_irq+0x492/0x7f0
pc : [<901408be>]    lr : [<90140c76>]    Not tainted
sp : 93aa399c  r12: fffffffe  r11: 00000000

r10: 00000000 r9 : fffffffe r8 : 00000000
r7 : 93aa3a08 r6 : 93406400 r5 : 00820004 r4 : 00000003 r3 : 00000008 r2 : 00000002 r1 : fffffffd r0 : 93837000

Call trace:
 [<90134abc>] usb_hcd_irq+0x50/0x54
 [<900383da>] handle_IRQ_event+0x1e/0x40
 [<90039098>] handle_level_irq+0x78/0x8c

...

This is on an AVR32 platform, and I'm building the kernel myself (cross compiling). The image is then converted to a uImage before being loaded to the target. Is there a way to get the following to work in this context?

$ gdb arch/avr32/boot/images/vmlinux.elf 
...
Reading symbols from /home/.../linux-2.6.37/arch/avr32/boot/images/vmlinux.elf...done.
(gdb) list *isp1760_irq+0xda
0x9017ac36 is in isp1760_irq (include/linux/spinlock.h:285).
280		raw_spin_lock_init(&(_lock)->rlock);		\
281	} while (0)
282	
283	static inline void spin_lock(spinlock_t *lock)
284	{
285		raw_spin_lock(&lock->rlock);
286	}
287	
288	static inline void spin_lock_bh(spinlock_t *lock)
289	{

The problem is that the line reported is totally wrong (this being very unhelpful and confusing indeed - it tool me awhile to realise this!). I've also tried to use gdb from the avr32 toolchain with the same result.

Is there a way to get this to work?

Thanks,
Arvid Brodin
Enea Services Stockholm AB

author
#1 lore raw
Quoted 48 lines · Arvid Brodin

Hi,

I'm trying to debug a kernel panic (something like this):

Unable to handle kernel NULL pointer dereference at virtual address 00000014
ptbr = 93959000 pgd = 93a0a000
Oops: Kernel access of bad area, sig: 11 [#1]
FRAME_POINTER chip: 0x01f:0x1e82 rev 2
Modules linked in: ftdi_sio usbserial
PC is at isp1760_irq+0xda/0x7f0
LR is at isp1760_irq+0x492/0x7f0
pc : [<901408be>]    lr : [<90140c76>]    Not tainted
sp : 93aa399c  r12: fffffffe  r11: 00000000

r10: 00000000 r9 : fffffffe r8 : 00000000
r7 : 93aa3a08 r6 : 93406400 r5 : 00820004 r4 : 00000003 r3 : 00000008 r2 : 00000002 r1 : fffffffd r0 : 93837000

Call trace:
 [<90134abc>] usb_hcd_irq+0x50/0x54
 [<900383da>] handle_IRQ_event+0x1e/0x40
 [<90039098>] handle_level_irq+0x78/0x8c

...

This is on an AVR32 platform, and I'm building the kernel myself (cross compiling). The image is then converted to a uImage before being loaded to the target. Is there a way to get the following to work in this context?

$ gdb arch/avr32/boot/images/vmlinux.elf 
...
Reading symbols from /home/.../linux-2.6.37/arch/avr32/boot/images/vmlinux.elf...done.
(gdb) list *isp1760_irq+0xda
0x9017ac36 is in isp1760_irq (include/linux/spinlock.h:285).
280		raw_spin_lock_init(&(_lock)->rlock);		\
281	} while (0)
282	
283	static inline void spin_lock(spinlock_t *lock)
284	{
285		raw_spin_lock(&lock->rlock);
286	}
287	
288	static inline void spin_lock_bh(spinlock_t *lock)
289	{

The problem is that the line reported is totally wrong (this being very unhelpful and confusing indeed - it tool me awhile to realise this!). I've also tried to use gdb from the avr32 toolchain with the same result.

Quoted 5 lines

Is there a way to get this to work?

Thanks,
Arvid Brodin
Enea Services Stockholm AB

To reply to my own email, the problem probably has to do with the fact that the kernel is built with optimization. Modifying KBUILD_CFLAGS in the Makefile to specify -O1 made things a lot better (although you still cannot rely completely on the line number reported). Unfortunately, the kernel won't build with -O0.

Signature · 2 lines
Arvid Brodin
Enea Services Stockholm AB
#2 lore raw
Quoted 4 lines · Arvid Brodin

To reply to my own email, the problem probably has to do with the fact that the kernel is built with optimization. Modifying KBUILD_CFLAGS in the Makefile to specify -O1 made things a lot better (although you still cannot rely completely on the line number reported). Unfortunately, the kernel won't build with -O0.

make sure frame pointer is included too

Signature · 7 lines
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com