From owner-freebsd-fs Mon Feb 25 14:30:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 9406637B402; Mon, 25 Feb 2002 14:30:12 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Feb 2002 22:30:11 +0000 (GMT) To: Kris Kennaway Cc: mckusick@mckusick.com, fs@FreeBSD.org, dillon@FreeBSD.org, fanf@chiark.greenend.org.uk Subject: Re: UFS panic on -stable In-Reply-To: Your message of "Mon, 25 Feb 2002 13:17:14 PST." <20020225131714.B59373@xor.obsecurity.org> Date: Mon, 25 Feb 2002 22:30:11 +0000 From: Ian Dowse Message-ID: <200202252230.aa23166@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020225131714.B59373@xor.obsecurity.org>, Kris Kennaway writes: >Here you go, hope I got everything: Mostly :-) Could you print out "*(struct proc *)0xcc2fba00", as the `p' pointer in frame 18 got lost. I just want to see what process was exiting to see if it offers any further hints. The superblock claims that this is a 2MB "/dev" filesystem - is that a real disk filesystem, or mounted from a vnconfig disk or something? In the vnode we have v_type set to VNON, v_mount is non-NULL, v_data is non-NULL, i_mode was 0666. Candidates I could see for leaving vnodes like this are getnewvnode() and the weird code in ufs_mknod(). I guess ufs_mknod is the main suspect since the filesystem is /dev. I wonder is the new vlrureclaim() code somehow reclaiming vnodes at a bad time. Maybe try setting kern.maxvnodes to some really large value to see if it stops the crashes, or set it very small and see if they occur more frequently. Matt, can you see any way that the weird/broken ufs_mknod() code could interact badly with vlrureclaim()? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message