Date: Thu, 29 May 1997 16:05:49 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: rsanders@mindspring.net Cc: current@FreeBSD.ORG Subject: Re: Boom! :-) Message-ID: <199705291405.QAA22937@pat.idt.unit.no> In-Reply-To: Your message of "29 May 1997 01:57:18 -0400" References: <knenaqbz29.fsf@xena.mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Doug Rabson <dfr@nlsystems.com> writes: > > > This is a workaround for the lockstatus panic. A better fix will probably > > have to wait until Peter is finished with poll(2). > > That seems to have helped with the lockstatus panic. Now I have a > different problem, detailed below. [...] > (kgdb) p *vp > $3 = {v_flag = 768, v_usecount = 0, v_writecount = 0, v_holdcnt = 0, ^^^ ^ VXLOCK | VXWANT, and a `free' vnode [...] > Should this vnode exist without an underlying inode? I know very > little about the BSD kernel, so excuse the naive question. This occurs during cleaning, for a very short interval, where nothing should block. In this case, something blocked. > This may simply be superstition, but these panics always follow within > an update period of me killing pppd to bring down a kernel PPP > connection. It does seem significant that v_type = VCHR and the > problem seems to coincide with me closing a PPP session on a character > device (/dev/cuaa2). Unfortunately, without knowing what inode v_data > used to point to, I suppose there's no way to trace the origin on this > vnode. If you perform a `ps axl' on the kernel/core combination, one process should be marked as being in `vn_loc'. If you look at the kernel stack trace of that process, you'll probably see more useful info (e.g. a deadlock). Try updating to revision 1.40 of src/sys/miscfs/specfs/spec_vnops.c. - Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705291405.QAA22937>