From owner-freebsd-current@FreeBSD.ORG Sat Dec 13 22:31:18 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F74516A4CE; Sat, 13 Dec 2003 22:31:18 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D26F43DCA; Sat, 13 Dec 2003 22:26:38 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hBE6JpeF064409; Sat, 13 Dec 2003 22:20:00 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200312140620.hBE6JpeF064409@gw.catspoiler.org> Date: Sat, 13 Dec 2003 22:19:51 -0800 (PST) From: Don Lewis To: jroberson@chesapeake.net In-Reply-To: <20031212065656.R4201-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: mckusick@mckusick.com cc: alc@FreeBSD.org cc: mb@imp.ch cc: freebsd-current@FreeBSD.org Subject: Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2003 06:31:18 -0000 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 > 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.