NetBSD Problem Report #28705

From dan@mcmahill.net  Sat Dec 18 20:17:28 2004
Return-Path: <dan@mcmahill.net>
Received: from canolog.ninthwonder.com (canolog.ninthwonder.com [198.69.224.202])
	by narn.netbsd.org (Postfix) with SMTP id 95EFE63B844
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 18 Dec 2004 20:17:22 +0000 (UTC)
Message-Id: <200412182016.iBIKGqR8015212@bondage.mcmahill.net>
Date: Sat, 18 Dec 2004 15:16:52 -0500 (EST)
From: dmcmahill@NetBSD.org
Reply-To: dmcmahill@NetBSD.org
To: gnats-bugs@netbsd.org
Subject: 2.0 kernel panic in layer_unlock with "vnode: table is full"
X-Send-Pr-Version: 3.95

>Number:         28705
>Category:       kern
>Synopsis:       2.0 kernel panic in layer_unlock with "vnode: table is full"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dholland
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 18 20:18:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Sun May 01 00:18:16 +0000 2011
>Originator:     Dan McMahill
>Release:        NetBSD 2.0
>Organization:
NetBSD
>Environment:


System: NetBSD bondage 2.0 NetBSD 2.0 (BONDAGE) #0: Fri Dec 10 22:57:37 EST 2004 mcmahill@slashing:/usr/cvs/obj.alpha/sys/arch/alpha/compile/BONDAGE alpha
Architecture: alpha
Machine: alpha
>Description:

during a bulk pkgsrc build (not sure exactly where in the build, I was away),
I got a kernel panic with a 2.0 kernel.

stack trace:

db> bt
cpu_Debugger() at netbsd:cpu_Debugger+0x4
panic() at netbsd:panic+0x1f8
lockmgr() at netbsd:lockmgr+0x308
layer_unlock() at netbsd:layer_unlock+0x98
VOP_UNLOCK() at netbsd:VOP_UNLOCK+0x3c
vput() at netbsd:vput+0x5c
lookup() at netbsd:lookup+0x44c
namei() at netbsd:namei+0x1bc
sys___lstat13() at netbsd:sys___lstat13+0x5c
syscall_plain() at netbsd:syscall_plain+0xc4
XentSys() at netbsd:XentSys+0x5c
--- syscall (280) ---
--- user mode ---


>How-To-Repeat:
not sure.  I'll see if it happens again.  If there is any other info
I should get if it happens again, please let me know.

>Fix:


>Release-Note:

>Audit-Trail:
From: Dan McMahill <dmcmahill@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/28705: 2.0 kernel panic
Date: Mon, 20 Dec 2004 08:08:57 -0500

 here is a little more info.  It happened again last night.  I had
 a bulk pkgsrc build going and it was during the daily script and I
 guess was probably in the the phase where it looks for core dumps
 with find.  The last thing I got on the serial console was:

 /netbsd: vnode: table is full - increase kern.max
 vnodes or NVNODE
 Dec 20 03:58:20 bondage last message repeated 47 times

 ^^^ this is new info

 panic: lockmgr: release of unlocked lock!
 Stopped in pid 21162.1 (find) at        netbsd:cpu_Debugger+0x4:        ret     
 zero,(ra)

 ^^^ this is new info

 The stack trace didn't change:

 db> bt
 cpu_Debugger() at netbsd:cpu_Debugger+0x4
 panic() at netbsd:panic+0x1f8
 lockmgr() at netbsd:lockmgr+0x308
 layer_unlock() at netbsd:layer_unlock+0x98
 VOP_UNLOCK() at netbsd:VOP_UNLOCK+0x3c
 vput() at netbsd:vput+0x5c
 lookup() at netbsd:lookup+0x44c
 namei() at netbsd:namei+0x1bc
 sys___lstat13() at netbsd:sys___lstat13+0x5c
 syscall_plain() at netbsd:syscall_plain+0xc4
 XentSys() at netbsd:XentSys+0x5c
 --- syscall (280) ---
 --- user mode ---
 db> 

 -Dan
 -- 

From: Dan McMahill <dmcmahill@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/28705: 2.0 kernel panic
Date: Mon, 20 Dec 2004 08:47:30 -0500

 one more bit.  I had kern.maxvnodes = 4988.  I'm trying again after upping
 this to 65536

 -Dan

 -- 

State-Changed-From-To: open->feedback
State-Changed-By: pooka@narn.netbsd.org
State-Changed-When: Sun, 20 Jan 2008 16:21:18 +0200
State-Changed-Why:
Can you try to repeat this with a later release?  It's most likely
an error in some error branch, but since there have been so many
changes to the area, it might have been accidentally fixed.  Setting
kern.maxvnodes low is the key.


Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 15 Nov 2009 00:06:59 +0000
Responsible-Changed-Why:
locking problem in lookup. (note: PR is in feedback wanting testing on a
recent release; would be helpful if that could get done)


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 01 May 2011 00:18:16 +0000
State-Changed-Why:
Feedback timeout. Anyone have a crash machine to try this on? If not I'll
get to it eventually. Judging by the connection to the vnode table filling
up I suspect it's probably a vnode lifecycle issue, in which case we can
hope it's fixed, or an error path bug in layerfs, in which case it probably
isn't.


>Unformatted:

Home	PR Database Search