NFS activity generates panic - looks like rm -rf kills it.

[Don Lee <MacPPC2%c.icompute.com@localhost>]

I've hit a panic on my production NetBSD 6.0.6 machine, and need to get it stable again. The machine seems to hit this panic when the NFS activity is "too much", where "too much" is a large number of filesystem ops happening "too quickly".

The traceback in the logs:

Apr 11 00:48:54 charm syslogd[150]: restart
Apr 11 00:48:54 charm /netbsd: panic: lock error 
Apr 11 00:48:54 charm /netbsd: cpu0: Begin traceback...
Apr 11 00:48:54 charm /netbsd: printf_nolog(c0ba4a09,c0b73822,c0ac5768,c0b72897,c4a13c60,0,c408e560,0,1,db9da840) at netbsd:printf_nolog
Apr 11 00:48:54 charm /netbsd: lockdebug_abort(c4a13c60,c0c32444,c0ac5768,c0b72897,db9da8b0,c0546db5,5e,0,a,0) at netbsd:lockdebug_abort+0x2b
Apr 11 00:48:54 charm /netbsd: rw_abort.clone.1(5e,0,a,0,c06042e5,5e,3,0,0,1) at netbsd:rw_abort.clone.1+0x32
Apr 11 00:48:54 charm /netbsd: rw_vector_enter(c4a13c60,1,1,c4a13bbc,20000,db9da8f0,c08ac762,db9da8e0,0,0) at netbsd:rw_vector_enter+0x2a0
Apr 11 00:48:54 charm /netbsd: genfs_lock(db9da8e0,0,0,c0b15a74,c4a13bbc,2,c4a13bbc,db9da910,c08905ce,c4a13bbc) at netbsd:genfs_lock+0x95
Apr 11 00:48:54 charm /netbsd: VOP_LOCK(c4a13bbc,2,2,c4a13bbc,0,82c1,db9daa24,c0626c82,c4a13bbc,20002) at netbsd:VOP_LOCK+0x4a
Apr 11 00:48:54 charm /netbsd: vn_lock(c4a13bbc,20002,c45e6180,5dc,14,42,14,c3c6baf4,0,c4a4a900) at netbsd:vn_lock+0x76
Apr 11 00:48:54 charm /netbsd: nfs_lookup(db9daa38,c0534e38,0,c0b15648,c4a13bbc,db9daa84,db9dac7c,c4a13bbc,db9daa94,c08826bd) at netbsd:nfs_lookup+0xfda
Apr 11 00:48:54 charm /netbsd: VOP_LOOKUP(c4a13bbc,db9daa84,db9dac7c,0,c0b15a74,c4a13bbc,c49cf6e4,db9dac58,db9dab58,c408e560) at netbsd:VOP_LOOKUP+0x50
Apr 11 00:48:54 charm /netbsd: lookup_once(db9dab28,db9dab24,4,c3712b30,c38df420,c4a13bbc,c3712b30,c3712b30,0,db9dabf4) at netbsd:lookup_once+0x176
Apr 11 00:48:54 charm /netbsd: namei_tryemulroot(0,db9dac58,db9dac7c,20,0,0,db9dac58,db9dac34,c0890004,db9dac58) at netbsd:namei_tryemulroot+0x1c9
Apr 11 00:48:54 charm /netbsd: namei(db9dac58,6,0,0,c0534c01,c0c8ce40,c3aab300,0,c45e6180,c408e560) at netbsd:namei+0x41
Apr 11 00:48:54 charm /netbsd: vn_open(db9dac58,1,949,1,c38ec340,1,c3791e40,c3791e40,c4502000,c38df420) at netbsd:vn_open+0x8c
Apr 11 00:48:54 charm /netbsd: do_open(bbb5c95b,db9dacc0,db9daccc,c408e560,c3791e40,c408e560,db9dad3c,c07b225a,c408e560,db9dad00) at netbsd:do_open+0x9b
Apr 11 00:48:54 charm /netbsd: sys_open(c408e560,db9dad00,db9dad28,5,c4872440,bb90b000,db9dad00,c49cf6e4,2,bbaee577) at netbsd:sys_open+0x4f
Apr 11 00:48:54 charm /netbsd: syscall(db9dad48,bbbc00b3,ab,bfbf001f,bbbc001f,bb90ad70,ffffffff,bfbfeb94,bbbc65bc,bb90ad70) at netbsd:syscall+0xaa
Apr 11 00:48:54 charm /netbsd: cpu0: End traceback...
Apr 11 00:48:54 charm /netbsd: 
Apr 11 00:48:54 charm /netbsd: dump to dev 0,1 not possible    
Apr 11 00:48:54 charm /netbsd: rebooting...
Apr 11 00:48:54 charm /netbsd: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,


This traceback is from the same scenario after I duplicated the machine and upgraded to 6.1.5 in hopes of having a fix. No dice.

Anyone seen this? Is there a workaround?


Thanks for any help,

-dgl-