>Number:         32338
>Category:       kern
>Synopsis:       NFS locks up hard, UVM problem?
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 19 13:55:00 +0000 2005
>Originator:     Reinoud Zandijk
>Release:        NetBSD 3.99.14 client / NetBSD 2.99.16 server
>Organization:
NetBSD
	
>Environment:
Server: NetBSD/Sparc, 2.01 userland (AFAIK)
Client: NetBSD/i386, 2.10 userland
Architecture: i386
Machine: i386
>Description:
Client machine seems to work fine but when doing a `make depend' in a 
source directory over NFS it first waits on `[netio]' but never ends. When 
listing the directory on a different shell i get a wait on '[vnlock]' or 
'[nfssrvlock]'. This continues forever.

Since the 2nd shell is waiting on a vnlock, i suspect the problem is in 
directory reading code of NFSv3 on the client side.

Note that on the same kernel (though with UDF support enabled), i get weird 
behaviour when globbing directories too: It starts with a normal directory 
read, correctly reissues the VOP_READDIR with the correct offsets but at 
the end when i signal the eof and don't copy in anything anymore (and non 
glob operations finish correctly) i get a spurious VOP_READDIR call with a 
wierd offset that i never returned; like it sets back the offset a hundred 
bytes or so. The UDF code then returns an error for it detects a broken 
directory entry.

Is the NFSv3 code getting that spurious VOP_READDIR call too with a wierd 
cookie and offset and gets completely confused or doesn't respond correctly 
on the NFS server's response?

>How-To-Repeat:

For me, execute a `makedep *.c' on a NFSv3 mounted directory and it hangs.

	
>Fix:
Explicitly mount with NFS version 2 i.e. `mount_nfs -2'. This won't lock up 
the machine anymore.