Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released

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.