Re: netbsd-5 NFS(?) lock up

[Andrew Doran <ad%netbsd.org@localhost>]

On Tue, Mar 31, 2009 at 03:39:44PM +0200, Manuel Bouyer wrote:

> Mutex error: lockdebug_wantlock: locking against myself
> 
> lock address : 0x00000000ce88c028 type     :     sleep/adaptive
> initialized  : 0x00000000c03a5052
> shared holds :                  0 exclusive:                  1
> shares wanted:                  0 exclusive:                 11
> current cpu  :                  1 last held:                  1
> current lwp  : 0x00000000ce8edcc0 last held: 0x00000000ce8edcc0
> last locked  : 0x00000000c03aeff4 unlocked : 0x00000000c025da80
> owner field  : 0x00000000ce8edcc0 wait/spin:                1/0
> 
> Turnstile chain at 0xc0704e60.
> => Turnstile at 0xce955788 (wrq=0xce955798, rdq=0xce9557a0).
> => 0 waiting readers:
> => 10 waiting writers: 0xce943d00 0xce943300 0xce8f2560 0xce8ed7c0 0xce465020 
> 0xce8f22e0 0xce8f2a60 0xce8eda40 0xce8f2ce0 0xce4652a0
> 
> panic: LOCKDEBUG
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 eip c03f0e2c cs 8 eflags 246 cr2 cdee3000 ilevel 0
> Stopped in pid 261.1 (nfsd) at  netbsd:breakpoint+0x4:  popl    %ebp
> db{1}> tr
> breakpoint(c0641842,ce918728,c2cec800,c035aaaf,0,1,0,0,ce918728,8) at 
> netbsd:breakpoint+0x4
> panic(c0641844,c063d60e,c051629b,c063d5dd,b4a8,18edcc0,0,d08fef18,0,ce88c028) 
> at netbsd:panic+0x1b0
> lockdebug_abort1(c063d5dd,1,0,0,cbf524d0,ce8ede78,0,6,d0821438,ce918b10) at 
> netbsd:lockdebug_abort1+0xbb
> mutex_vector_enter(ce88c028,11,ce918b6c,c025cc47,ce88c000,0,cbf66300,ce44692c,c3b92c00,ce918b58)
>  at netbsd:mutex_vector_enter+0x464
> genfs_renamelock_enter(ce88c000,0,cbf66300,ce44692c,c3b92c00,ce918b58,ce918b54,ce918b44,ce8edcc0,0)
>  at netbsd:genfs_renamelock_enter+0x14
> nfsrv_rename(d0c8ca20,ce44692c,ce8edcc0,ce918bd0,cd117b40,c0701d58,0,c2cec918,c0701d58,0)
>  at netbsd:nfsrv_rename+0x4b7
> nfssvc_nfsd(ce918c38,804a2e0,ce8edcc0,0,0,0,0,0,0,ffffffff) at 
> netbsd:nfssvc_nfsd+0x3d6
> sys_nfssvc(ce8edcc0,ce918d00,ce918d28,bfbff000,ce478684,ce478684,2,4,804a2e0,bfbfee94)
>  at netbsd:sys_nfssvc+0x332
> syscall(ce918d48,b3,ab,bfbf001f,bbbd001f,11,1,bfbfee94,0,bfbffff0) at 
> netbsd:syscall+0xc8
> db{1}> mach cpu 0
> using CPU 0

I can't see what's causing this to happen, although with all the macros the
NFS source can be a bit of a minefield (lots going on behind the scenes).
Sadly the "last locked" address is a bit useless because it's always going
to be genfs_renamelock_enter().

David does NFS really need this lock? I think not...