Date: Mon, 17 Jan 2011 11:48:40 +0100 From: Miki Magyari <magyarimiki@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: problem debugging kernel module using kernel crash dump with kgdb Message-ID: <AANLkTi=EdTn96-bF7xDxBD%2B9DwgQeDrJV7hCn5KBZK7B@mail.gmail.com> In-Reply-To: <AANLkTi=%2BZOdjiq-SArU8%2B3t_4qvoOzK-LPhdFjFJ1EeG@mail.gmail.com> References: <AANLkTi=%2BZOdjiq-SArU8%2B3t_4qvoOzK-LPhdFjFJ1EeG@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 16, 2011 at 7:57 PM, Miki Magyari <magyarimiki@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 =A0doadump () at pcpu.h:246 > #1 =A00xc089cb9e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown= .c:416 > #2 =A00xc089ce72 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 =A00xc04d1ab7 in db_panic (addr=3DCould not find the frame base for "d= b_panic". > ) at /usr/src/sys/ddb/db_command.c:478 > #4 =A00xc04d20e1 in db_command (last_cmdp=3D0xc0dd2f5c, cmd_table=3D0x0, > dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > #5 =A00xc04d223a in db_command_loop () at /usr/src/sys/ddb/db_command.c:4= 98 > #6 =A00xc04d40dd in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_m= ain.c:229 > #7 =A00xc08cc4e6 in kdb_trap (type=3D3, code=3D0, tf=3D0xc8caa818) at > /usr/src/sys/kern/subr_kdb.c:535 > #8 =A00xc0bd4a9b in trap (frame=3D0xc8caa818) at /usr/src/sys/i386/i386/t= rap.c:690 > #9 =A00xc0bb5f7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc08cc66a in kdb_enter (why=3D0xc0cab4ec "panic", msg=3D0xc0cab4ec > "panic") at cpufunc.h:71 > #11 0xc089ce56 in panic (fmt=3D0xc0ca9eb8 "mtx_lock() of spin mutex %s @ > %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573 > #12 0xc088d4ea in _mtx_lock_flags (m=3D0xc2911904, opts=3D0, > file=3D0xc0cb66ca "/usr/src/sys/kern/vfs_bio.c", line=3D2545) at > /usr/src/sys/kern/kern_mutex.c:197 > #13 0xc091a282 in getblk (vp=3D0xc2911810, blkno=3D2, size=3D512, slpflag= =3D0, > slptimeo=3D0, flags=3D0) at /usr/src/sys/kern/vfs_bio.c:2545 > #14 0xc091ab24 in breadn (vp=3D0xc2911810, blkno=3DUnhandled dwarf > expression opcode 0x93 > ) at /usr/src/sys/kern/vfs_bio.c:800 > #15 0xc091ac9c in bread (vp=3D0xc2911810, blkno=3DUnhandled dwarf > expression opcode 0x93 > ) at /usr/src/sys/kern/vfs_bio.c:748 > #16 0xc286d5b4 in minixfs_mount (mp=3D0xc2492000) at > /usr/src/sys/modules/minixfs/../../fs/minixfs/minixfs_vfsops.c:149 > #17 0xc09290a8 in vfs_donmount (td=3D0xc2817280, fsflags=3D0, > fsoptions=3D0xc2499780) at /usr/src/sys/kern/vfs_mount.c:988 > #18 0xc092a7e5 in nmount (td=3D0xc2817280, uap=3D0xc8caacf8) at > /usr/src/sys/kern/vfs_mount.c:424 > #19 0xc0bd4220 in syscall (frame=3D0xc8caad38) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=EdTn96-bF7xDxBD%2B9DwgQeDrJV7hCn5KBZK7B>