HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released
Don Lewis
truckman at FreeBSD.org
Sat Dec 13 22:31:18 PST 2003
On 12 Dec, Jeff Roberson wrote:
> fsync: giving up on dirty: 0xc4e18000: tag devfs, type VCHR, usecount 44,
> writecount 0, refcount 14, flags (VI_XLOCK|VV_OBJBUF), lock type devfs: EXCL
> (count 1) by thread 0xc20ff500
Why are we trying to reuse a vnode with a usecount of 44 and a refcount
of 14? What is thread 0xc20ff500 doing?
> Locked vnodes
> 0xc4e16b2c: tag ufs, type VDIR, usecount 10, writecount 0, refcount 2,
> flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc4ac0c80
> ino 2, on dev ar0s1a (4, 31)
> 0xc4e16a28: tag syncer, type VNON, usecount 1, writecount 0, refcount 1,
> lock type syncer: EXCL (count 1) by thread 0xc4ac0c80
>
>
> Looks like we're syncing the root inode for this filesystem. Here's the
> buffer:
> b_flags = 0x200202a0<vmio,clusterok,done,delwri,cache>
> b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0
> b_dev = (4,31), b_data = 0xcf4de000, b_blkno = 224
> b_npages = 4, pages(OBJ, IDX, PA):
> (0, 0x1c, 0x181ef000),
> (0, 0x1d, 0x17e50000),
> (0, 0x1e, 0x180d1000),
> (0, 0x1f, 0x180b2000)
Are we sure this buf is associated with the root vnode?
> And the page addresses:
> 0xcee4a120: c1b04af0 c1af4638 c1affa80 c1aff1c8
>
> first page
> 0xc1b04af0: c1b041f0 c09522a0 c1af4638 c4e17770
> 0xc1b04b00: 0 c1ae4330 0 1c
> 0xc1b04b10: 0 181ef000 0 0
> 0xc1b04b20: c1b04b1c 0 1000f 0
> 0xc1b04b30: ff 0
>
> The page looks valid. Flags are 0, valid is 0xff, one of the splay
> pointers is NULL, and the object is null. The pages are all within the
> vm_page_array.
>
> The things that stand out to me, are the fsync failure, which
> interestingly points to a VCHR vnode locked with XLOCK. This is during
> sysinstall, so I'm not sure why we'd be xlocking anything, but I don't
> know much about the mechanics of sysinstall. Also, the NULL object is
> quite confusing since we have valid looking object offsets.
The NULL object looks seriously bogus. If there isn't a valid
vm_object, then the B_VMIO flag should be clear, and vfs_setdirty()
should return immediately.
More information about the freebsd-current
mailing list