The following reply was made to PR kern/29670; it has been noted by GNATS.

From: Ken Raeburn <raeburn@raeburn.org>
To: gnats-bugs@netbsd.org
Cc: Ken Raeburn <raeburn@raeburn.org>
Subject: Re: kern/29670: lockmgr: locking against myself
Date: Sat, 26 Mar 2005 13:23:34 -0500

 On Mar 21, 2005, at 13:37, Ken Raeburn wrote:
 > Another crash (with 2.0+vfs_lookup.c:1.57) in pretty much the same  
 > place, yesterday morning; here's the stack trace pulled out of the  
 > message buffer:
 
 This is getting pretty persistent.  Two more hangs of this sort since I  
 sent this mail (plus one odd hang while syncing file systems after I  
 told it to reboot after I got the table-full message).  Very similar  
 circumstances -- vnode table is reported as full, and then the "locking  
 against myself" panic in a stat call on  
 <daily-working-directory>/krb5-current/src/kadmin/testing/krb5-test- 
 root/krb5.conf.  The vnode free list has only one entry, which has  
 v_flag 0x2100 (VLAYER|VXLOCK).  desiredvnodes is 23526, but numvnodes  
 is a bit larger (30465, 29427).  So getnewvnode won't try to allocate a  
 new node, and getcleanvnode tries only the free list and can't find an  
 entry without VXLOCK set.  (In at least one of these crashes,  
 vnode_hold_list appears to have some vnodes that would've been useable,  
 but getcleanvnode only looks at the hold list if the free list is  
 actually empty.)
 
 The lock that genfs_lock is trying to acquire is already locked via  
 genfs_lock.  Unfortunately, there's no record of where *that* was  
 called from, or an indication if it's in the current stat call or from  
 something earlier.
 
 The machine hung, didn't reboot, after the panic; the stack trace shown  
 by gdb seems to be for the ddb keyboard interrupt in aiodoned process I  
 used to manually force the crash dump, *not* for the panic; I'm not  
 sure how to get gdb to see the stack trace reported by the panic  
 message.
 
 Ken