From owner-freebsd-current  Thu May 29 07:10:03 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA15046
          for current-outgoing; Thu, 29 May 1997 07:10:03 -0700 (PDT)
Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA15014
          for <current@FreeBSD.ORG>; Thu, 29 May 1997 07:10:00 -0700 (PDT)
Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65])
	by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id QAA22937;
	Thu, 29 May 1997 16:05:50 +0200 (MET DST)
Message-Id: <199705291405.QAA22937@pat.idt.unit.no>
To: rsanders@mindspring.net
Cc: current@FreeBSD.ORG
Subject: Re: Boom! :-)
In-Reply-To: Your message of "29 May 1997 01:57:18 -0400"
References: <knenaqbz29.fsf@xena.mindspring.com>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 29 May 1997 16:05:49 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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