From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 17 10:48:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA57106566B for ; Mon, 17 Jan 2011 10:48:42 +0000 (UTC) (envelope-from magyarimiki@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id F2C858FC13 for ; Mon, 17 Jan 2011 10:48:41 +0000 (UTC) Received: by qyk8 with SMTP id 8so1336405qyk.13 for ; Mon, 17 Jan 2011 02:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=4bx2JFQdMM6jPChIVhlx5XvV8k33PkK6k6V0T9Ae9yU=; b=fG3gYXQ5n3qwLuVZr+yifrv+4aC0l+1VpsLcZ5bJ9vYaCfWU1yLBXnVHhW01skz+j4 1eHylWzCbUOhzupyuSloWdP3/gfbhnpjpEcgRwY+VqsrLRHCUiLxGfguH/bfSeWy0mxe a2yHpVi8eSOvzSfM3TOtF8b7nnOtps/iAA/mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WLjV4aH53/HLMEbdnpEVu4ELSRgRif6oukX96OD4mcMieRTPgUUiqLT27wtBRf419W Iw3P67LU6K2TI/uDfGYMDUfo4Vx6gEYL97sU3cUFOFGcvTLqJeuvEo+3JgmLwI4trbc6 3/Y7iaGaTRh9Of0gMD2HnOZ9BCVj4Jw5FvKsQ= MIME-Version: 1.0 Received: by 10.224.179.76 with SMTP id bp12mr3716114qab.264.1295261320848; Mon, 17 Jan 2011 02:48:40 -0800 (PST) Received: by 10.220.166.6 with HTTP; Mon, 17 Jan 2011 02:48:40 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Jan 2011 11:48:40 +0100 Message-ID: From: Miki Magyari To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: problem debugging kernel module using kernel crash dump with kgdb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:48:42 -0000 On Sun, Jan 16, 2011 at 7:57 PM, Miki Magyari 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