Re: 6-current: udf broken, "locking against myself"

From: Scott Long <scottl_at_samsco.org>
Date: Mon, 11 Jul 2005 20:51:47 -0600
This should have been fixed by a commit a couple of days ago.  How old 
are your sources?

Scott

Martin Cracauer wrote:
> Further testing 6-current.  Seems like the udf filesystem is hosed, I
> cannot even use a minimal one.
> 
> Mounting a udf (data) filesystem works, but the first attempt to use it
> results in
> "panic: lockmgr: locking against myself".
> 
> I put an minimal testing image on:
> http://wavehh.dyndns.org/tmp/ll.udf.gz
> 
> It has been created with `mkisofs -udf dir` # no other options to mkisofs
> 
> Reproduce error:
> $ mdconfig -a -t vnode -f ll.udf
> md4
> $ mount_udf /dev/md4 /mnt/tmp                   # works
> $ cd /mnt/tmp                                   # still works
> $ ls                                            # panic
> 
> This is a single-processor i386 machine with a single-processor
> kernel.  Info on this machine (dmesg, pciconf, kernel config etc.) is
> on http://www.cons.org/cracauer/machines/grisu/
> 
> A quick check on a 2-processor box with SMP support shows the same
> panic.
> 
> Here are the symboled parts of the backtrace:
> #23 0xc05888e0 in kdb_enter (msg=0x0) at cpufunc.h:60
> #24 0xc056a4f5 in panic (fmt=0xc077896e "lockmgr: locking against myself")
>     at ../../../kern/kern_shutdown.c:537
> #25 0xc055baad in lockmgr (lkp=0xc2e27168, flags=12290, interlkp=0x80, 
>     td=0xc2d6b600) at ../../../kern/kern_lock.c:329
> #26 0xc05ca1cf in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:258
> #27 0xc074e364 in VOP_LOCK_APV (vop=0xc07b7500, a=0xf7cd8994)
>     at vnode_if.c:1642
> #28 0xc05e481c in vn_lock (vp=0xc2e27110, flags=4098, td=0xc2d6b600)
>     at vnode_if.h:844
> [addresses without symbols]
> #56 0xc074d40e in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at vnode_if.c:150
> 
> vnode_if.c:1642 is generated, it looks like this in this kernel (line
> marked in # comment).
> 
> int
> VOP_LOCK_APV(struct vop_vector *vop, struct vop_lock_args *a)
> {
>         int rc;
> 
>         VNASSERT(a->a_gen.a_desc == &vop_lock_desc, a->a_vp,
>             ("Wrong a_desc in vop_lock(%p, %p)", a->a_vp, a));
>         while(vop != NULL && \
>             vop->vop_lock == NULL && vop->vop_bypass == NULL)
>                 vop = vop->vop_default;
>         VNASSERT(vop != NULL, a->a_vp, ("No vop_lock(%p, %p)", a->a_vp, a));
>         vop_lock_pre(a);
>         if (vop->vop_lock != NULL)
>                 rc = vop->vop_lock(a); # this is the panic line 1642
>         else
>                 rc = vop->vop_bypass(&a->a_gen);
>         CTR3(KTR_VOP,
>             "VOP_LOCK(vp 0x%lX, flags %ld, td 0x%lX)",
>             a->a_vp, a->a_flags, a->a_td);
>         if (rc == 0) {
>         } else {
>         }
>         vop_lock_post(a, rc);
>         return (rc);
> }
> 
> Now, since I don't have anything useful in the backtrace, how do I go
> about debugging an error like this?
> 
> Martin
Received on Tue Jul 12 2005 - 00:51:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC