Subject: kern/32090: uvm_fault() after "vnode: table is full"
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
List: netbsd-bugs
Date: 11/16/2005 13:58:00
>Number:         32090
>Category:       kern
>Synopsis:       uvm_fault() after "vnode: table is full"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 16 13:58:00 +0000 2005
>Originator:     Manuel Bouyer
>Release:        NetBSD 2.1_STABLE
>Organization:
UPMC/LIP6/ASIM

>Environment:
System: NetBSD pop.lip6.fr 2.1_STABLE NetBSD 2.1_STABLE (GENERIC.MPDEBUG) #1: Wed Nov 2 13:30:15 CET 2005 bouyer@pop.lip6.fr:/local/pop1/bouyer/tmp/i386/obj/local/pop1/bouyer/netbsd-2/src/sys/arch/i386/compile/GENERIC.MPDEBUG i386
Architecture: i386
Machine: i386
>Description:
	This SMP box is doing pkgsrc bulk builds (in 2 chroots: one with
	1.6.2 binaries, one with 2.0).
	Today the system paniced after a stream of
vnode: table is full - increase kern.maxvnodes or NVNODE
	(which may or may not be the cause of the problem):
uvm_fault(0xcdc87004, 0x35a0000, 0, 1) -> 0xe

db{0}> tr
_simple_lock(35a0200,c0755bc0,5f1,8,0) at netbsd:_simple_lock+0x41
nfs_invaldircache(cf3bb884,1,ce165cbc,c0376aeb,cf3bb90c) at netbsd:nfs_invaldircache+0x52
nfs_inactive(ce165cd4,0,ce165cec,c03c67b1,c05f4f20) at netbsd:nfs_inactive+0x17d
VOP_INACTIVE(cf3bb884,cdc5b00c,54f,cf3bb8d4,c252e520) at netbsd:VOP_INACTIVE+0x28
vrele(cf3bb884,c07b1fa0,36a,c23acdc4,cdcafc30) at netbsd:vrele+0x124
layer_reclaim(ce165d54,c075e460,0,cdcafc30,c05f4f60) at netbsd:layer_reclaim+0x91
VOP_RECLAIM(cdcafc30,cdc5b00c,11,c07bdb40,cf3bb90c) at netbsd:VOP_RECLAIM+0x28
vclean(cdcafc30,8,cdc5b00c,2000,cdc5b00c) at netbsd:vclean+0x128
vgonel(cdcafc30,cdc5b00c,6bb,c07bdb40,cdcafc30) at netbsd:vgonel+0x56
vgone(cdcafc30,0,0,c07b3558,c05f4fa0) at netbsd:vgone+0x34
layer_inactive(ce165e24,0,ce165e3c,c03c67b1,c05f4f20) at netbsd:layer_inactive+0x3b
VOP_INACTIVE(cdcafc30,cdc5b00c,54f,cdcafc80,0) at netbsd:VOP_INACTIVE+0x28
vrele(cdcafc30,ce165ed0,ce165eac,c03c7510,cdcafc30) at netbsd:vrele+0x124
layer_remove(ce165e94,cebc2970,cdc5b00c,c2431600,c05f4ce0) at netbsd:layer_remove+0x42
VOP_REMOVE(cebc2970,cdcafc30,ce165ef8,2,0) at netbsd:VOP_REMOVE+0x2e
sys_unlink(ccb5ace4,ce165f64,ce165f5c,a,0) at netbsd:sys_unlink+0xfb
syscall_plain() at netbsd:syscall_plain+0x17e
--- syscall (number 10) ---
0x48217ee7:
db{0}> mach cpu 1
using CPU 1
db{0}> tr
acquire(c0828b40,cd6c5efc,400000,0,600) at netbsd:acquire+0x49
_lockmgr(c0828b40,400002,0,c075e460,54f) at netbsd:_lockmgr+0x4c0
_kernel_proc_lock(cdcc6ef8,cd6c5f64,4,6,cdcc6ef8) at netbsd:_kernel_proc_lock+0x
39
syscall_plain() at netbsd:syscall_plain+0x16f
--- syscall (number 6) ---
0x48052a47:

I have a core dump.

>How-To-Repeat:
	see above
>Fix:
	unknown