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>