> 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
[...]
> (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
This is just a glitch in gdb. The true value of ap is here:
> #3 0xc016cfbc in vop_stdlock (ap=0xc7482a64) at ../../kern/vfs_default.c:209
^^^^^^^^^^
I don't think that this dump is useful for debugging this problem. Perhaps, if
you compile the kernel with DEBUG_LOCKS, you will get more useful info.
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
