Date: Sat, 13 Dec 2003 22:19:51 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: jroberson@chesapeake.net Cc: freebsd-current@FreeBSD.org Subject: Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released Message-ID: <200312140620.hBE6JpeF064409@gw.catspoiler.org> In-Reply-To: <20031212065656.R4201-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312140620.hBE6JpeF064409>