Date: Thu, 3 Jun 1999 05:51:26 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG Cc: schimken@cs.rpi.edu Subject: Re: 3.2-STABLE, 11th panic Message-ID: <199906031251.FAA28209@salsa.gv.tsc.tdk.com> In-Reply-To: "David E. Cross" <crossd@cs.rpi.edu> "3.2-STABLE, 11th panic" (Jun 2, 11:40am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 2, 11:40am, "David E. Cross" wrote:
} Subject: 3.2-STABLE, 11th panic
} Here is a backtrace from our latest. Does anyone have any ideas to try. Is
} there any way to loock at who has the other lock on the file? (Yes, I know
} it is the kernel who has it, but it is requested on behalf of a NFSd, no?)
There isn't any easy way I know of to debug this. From the symptoms, it
sounds like nfsd sometimes forgets to release the lock and sometime later
tries to lock the same vnode.
The only way I can think to debug this is to hack together something
like DEBUG_LOCKS that stashes information about vget's caller in the
lock structure. You'll have to hack vget() to take the extra arguments
and pass them to debug_vn_lock() which needs to store them in the lock
structure. When the panic occurs, use gdb to print out *lkp in
debuglockmgr(), which will tell you where the vnode was previously locked.
Then you'll have to search forward from that point in the code to find
where it forgets to unlock the vnode. The ugly part is that vget() is
called all over the place, and you'll have to arrange for the extra
parameters to be passed to all these calls, though I think it should
be possible to do this with a macro. Hopefully the information you
get from this will be enough and you won't need to find the caller of
the caller of vget() ...
} (kgdb) bt
} #0 boot (howto=256) at ../../kern/kern_shutdown.c:285
} #1 0xc014baa4 in at_shutdown (
} function=0xc02354bb <__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+179>, arg=0xc74e9080, queue=65538) at ../../kern/kern_shutdown.c:446
} #2 0xc0147794 in debuglockmgr (lkp=0xc1528400, flags=16842754,
} interlkp=0xc74e90f0, p=0xc743eb20, name=0xc0237d57 "vop_stdlock",
} file=0xc023804b "../../kern/vfs_subr.c", line=1274)
} at ../../kern/kern_lock.c:326
} #3 0xc016d6c1 in vop_stdlock (ap=0xc7482a5c) at ../../kern/vfs_default.c:211
} #4 0xc01e5bfd in ufs_vnoperate (ap=0xc7482a5c)
} at ../../ufs/ufs/ufs_vnops.c:2299
} #5 0xc0176635 in debug_vn_lock (vp=0xc74e9080, flags=65538, p=0xc743eb20,
} filename=0xc023804b "../../kern/vfs_subr.c", line=1274) at vnode_if.h:811
} #6 0xc01700d1 in vget (vp=0xc74e9080, flags=2, p=0xc743eb20)
} at ../../kern/vfs_subr.c:1274
} #7 0xc016c1b3 in vfs_cache_lookup (ap=0xc7482b24)
} at ../../kern/vfs_cache.c:439
} #8 0xc01e5bfd in ufs_vnoperate (ap=0xc7482b24)
} at ../../ufs/ufs/ufs_vnops.c:2299
} #9 0xc016e7c1 in lookup (ndp=0xc7482d94) at vnode_if.h:31
} #10 0xc01b8260 in nfs_namei (ndp=0xc7482d94, fhp=0xc7482d0c, len=3,
} slp=0xc0f7e400, nam=0xc0f541a0, mdp=0xc7482c48, dposp=0xc7482c44,
} retdirp=0xc7482c2c, p=0xc743eb20, kerbflag=0, pubflag=0)
} at ../../nfs/nfs_subs.c:1642
} #11 0xc01a123f in nfsrv_lookup (nfsd=0xc13d3400, slp=0xc0f7e400,
} procp=0xc743eb20, mrq=0xc7482e34) at ../../nfs/nfs_serv.c:396
} #12 0xc01b9cba in nfssvc_nfsd (nsd=0xc7482e94, argp=0x8071af4 "", p=0xc743eb20)
} at ../../nfs/nfs_syscalls.c:656
} #13 0xc01b95d5 in nfssvc (p=0xc743eb20, uap=0xc7482f94)
} at ../../nfs/nfs_syscalls.c:342
} #14 0xc020d02f 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 0xc0203e5c in Xint0x80_syscall ()
} #16 0x80480e9 in ?? ()
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906031251.FAA28209>