problem debugging kernel module using kernel crash dump with kgdb

[Miki Magyari]

On Sun, Jan 16, 2011 at 7:57 PM, Miki Magyari <magyarimiki at gmail.com> wrote:
> hi,
>
> I'm new to kernel programming, working on a kernel module and trying
> to debug a crash dump after a panic. Here is the backtrace:
>
> (kgdb) bt
> #0  doadump () at pcpu.h:246
> #1  0xc089cb9e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
> #2  0xc089ce72 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:590
> #3  0xc04d1ab7 in db_panic (addr=Could not find the frame base for "db_panic".
> ) at /usr/src/sys/ddb/db_command.c:478
> #4  0xc04d20e1 in db_command (last_cmdp=0xc0dd2f5c, cmd_table=0x0,
> dopager=1) at /usr/src/sys/ddb/db_command.c:445
> #5  0xc04d223a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> #6  0xc04d40dd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
> #7  0xc08cc4e6 in kdb_trap (type=3, code=0, tf=0xc8caa818) at
> /usr/src/sys/kern/subr_kdb.c:535
> #8  0xc0bd4a9b in trap (frame=0xc8caa818) at /usr/src/sys/i386/i386/trap.c:690
> #9  0xc0bb5f7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #10 0xc08cc66a in kdb_enter (why=0xc0cab4ec "panic", msg=0xc0cab4ec
> "panic") at cpufunc.h:71
> #11 0xc089ce56 in panic (fmt=0xc0ca9eb8 "mtx_lock() of spin mutex %s @
> %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573
> #12 0xc088d4ea in _mtx_lock_flags (m=0xc2911904, opts=0,
> file=0xc0cb66ca "/usr/src/sys/kern/vfs_bio.c", line=2545) at
> /usr/src/sys/kern/kern_mutex.c:197
> #13 0xc091a282 in getblk (vp=0xc2911810, blkno=2, size=512, slpflag=0,
> slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2545
> #14 0xc091ab24 in breadn (vp=0xc2911810, blkno=Unhandled dwarf
> expression opcode 0x93
> ) at /usr/src/sys/kern/vfs_bio.c:800
> #15 0xc091ac9c in bread (vp=0xc2911810, blkno=Unhandled dwarf
> expression opcode 0x93
> ) at /usr/src/sys/kern/vfs_bio.c:748
> #16 0xc286d5b4 in minixfs_mount (mp=0xc2492000) at
> /usr/src/sys/modules/minixfs/../../fs/minixfs/minixfs_vfsops.c:149
> #17 0xc09290a8 in vfs_donmount (td=0xc2817280, fsflags=0,
> fsoptions=0xc2499780) at /usr/src/sys/kern/vfs_mount.c:988
> #18 0xc092a7e5 in nmount (td=0xc2817280, uap=0xc8caacf8) at
> /usr/src/sys/kern/vfs_mount.c:424
> #19 0xc0bd4220 in syscall (frame=0xc8caad38) at
> /usr/src/sys/i386/i386/trap.c:1111
> #20 0xc0bb5fe0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261

I'm really stuck with the above panic. I have the feeling it is
something wrong with my build as I can produce the same issue with
ext2fs code.

# cd /sys/modules/ext2fs
# make
# make load
# mount_ext2fs ...

causes the same "mtx_lock() of bufobj interlock..." panic.
Is it possible that building a module using the above steps produces a
.ko that not fully binary compatible with the running kernel? I'm not
using GENERIC but a custom kernel built with most of the debugging
stuff enabled (witness, invariants, diagnostic...).

(I have compared /boot/kernel/ext2fs.ko and ext2fs.ko produced by the
above steps and they differ)

Any pointers are warmly welcome..

br,
Miki