On Mon, Feb 07, 2005 at 09:49:41AM -0800, Bill Studenmund wrote:
> > > new conditional. If the printf() fires, we know we found the issue.
> 
> I assume that was the PDIRUNLOCK below?

Yes.

> 
> > Hi,
> > after about a week of compiles, I got this on the console:
> > Feb  4 03:21:24 folk /netbsd: vnode: table is full - increase kern.maxvnodes or NVNODE
> > Feb  4 03:21:24 folk last message repeated 135 times
> > Feb  5 07:27:11 lookup(): PDIRUNLOCK
> > folk /netbsd: vnode: table is full - increase kern.maxvnodes or NVNODE
> > Feb  5 07:27:12 folk last message repeated 2 times
> > 
> > The box didn't panic, but I can't log in. Lots of processes blocked on
> > vnlock. I have null mounts on this box (for the bulk build), with nullfs
> > loaded via LKM, maybe this is the reason. I've got a core dump from ddb.
> 
> I don't think LKM is the issue, nor is nullfs directly the issue. I think 
> the problem now is that you've hit a lingering low-resources issue. Either 
> NetBSD is somehow mis-handling the low-resources case (something we know 
> we aren't good at), or there's another bug in error-case handling that we 
> haven't found.
> 
> All I can think to do is further discuss this on tech-kern.
> 
> Oh, I think all the processes in vnlock aren't the core problem. Something 
> else has a vnlock and is waiting for some other resource that isn't there. 
> Then everything else piles up on the different vnlocks.

Could something with a vnlock try to allocate a new vnode ? If so this
is probably the source of the problem.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--