From owner-freebsd-hackers Tue May 25 18: 9: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id C69A914D8B for ; Tue, 25 May 1999 18:09:03 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA93769 for ; Tue, 25 May 1999 21:09:02 -0400 (EDT) Message-Id: <199905260109.VAA93769@cs.rpi.edu> To: hackers@freebsd.org Subject: kernel debugging assistance Date: Tue, 25 May 1999 21:09:02 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to trace down the cause of the recursive lock and I stumbled upon this: (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc014b3f4 in at_shutdown ( function=0xc0234aca <__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+154>, arg=0x10002, queue=-951064448) at ../../kern/kern_shutdown.c:446 #2 0xc01470f8 in lockmgr (lkp=0xc10d8f00, flags=16842754, interlkp=0xc74fe8f0, p=0xc743eb20) at ../../kern/kern_lock.c:326 #3 0xc016cfbc in vop_stdlock (ap=0xc7482a64) at ../../kern/vfs_default.c:209 #4 0xc01e4fad in ufs_vnoperate (ap=0xc7482a64) at ../../ufs/ufs/ufs_vnops.c:2299 #5 0xc0175d97 in vn_lock (vp=0xc74fe880, flags=65538, p=0xc743eb20) at vnode_if.h:811 #6 0xc016f93f in vget (vp=0xc74fe880, flags=2, p=0xc743eb20) at ../../kern/vfs_subr.c:1274 #7 0xc016bac7 in vfs_cache_lookup (ap=0xc7482b24) at ../../kern/vfs_cache.c:439 #8 0xc01e4fad in ufs_vnoperate (ap=0xc7482b24) at ../../ufs/ufs/ufs_vnops.c:2299 #9 0xc016e079 in lookup (ndp=0xc7482d94) at vnode_if.h:31 #10 0xc01b769c in nfs_namei (ndp=0xc7482d94, fhp=0xc7482d0c, len=3, slp=0xc0f7e600, nam=0xc0f54200, mdp=0xc7482c48, dposp=0xc7482c44, retdirp=0xc7482c2c, p=0xc743eb20, kerbflag=0, pubflag=0) at ../../nfs/nfs_subs.c:1642 #11 0xc01a068f in nfsrv_lookup (nfsd=0xc1185700, slp=0xc0f7e600, procp=0xc743eb20, mrq=0xc7482e34) at ../../nfs/nfs_serv.c:396 #12 0xc01b90f6 in nfssvc_nfsd (nsd=0xc7482e94, argp=0x8071af4 "", p=0xc743eb20) at ../../nfs/nfs_syscalls.c:656 #13 0xc01b8a11 in nfssvc (p=0xc743eb20, uap=0xc7482f94) at ../../nfs/nfs_syscalls.c:342 #14 0xc020bd5f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 8, tf_esi = 0, tf_ebp = -1077944892, tf_isp = -951570460, tf_ebx = 0, tf_edx = -1077945288, tf_ecx = 0, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 134518940, tf_cs = 31, tf_eflags = 642, tf_esp = -1077945280, tf_ss = 39}) at ../../i386/i386/trap.c:1100 #15 0xc0202b8c in Xint0x80_syscall () #16 0x80480e9 in ?? () (kgdb) up 3 #3 0xc016cfbc in vop_stdlock (ap=0xc7482a64) at ../../kern/vfs_default.c:209 209 return (lockmgr(l, ap->a_flags, &ap->a_vp->v_interlock, ap->a_p)); (kgdb) print ap $1 = (struct vop_lock_args *) 0x0 (kgdb) That doesn't seem to be possible, especially since ap->FOO is used in the same line.. wouldn't that cause a fault at this point? (it isn't the panic occurs later as you can see.) -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message