Date: Mon, 25 Feb 2002 22:30:11 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Kris Kennaway <kris@obsecurity.org> Cc: mckusick@mckusick.com, fs@FreeBSD.org, dillon@FreeBSD.org, fanf@chiark.greenend.org.uk Subject: Re: UFS panic on -stable Message-ID: <200202252230.aa23166@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 25 Feb 2002 13:17:14 PST." <20020225131714.B59373@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200202252230.aa23166>