Date: Fri, 18 Apr 1997 12:51:42 -0400 (EDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!labinfo.iet.unipi.it!luigi, ponds!lakes.water.net!rivers Cc: ponds!freefall.freebsd.org!freebsd-bugs Subject: Re: kern/3304: NFS V2 readdir hangs Message-ID: <199704181651.MAA08022@lakes.water.net>
next in thread | raw e-mail | index | archive | help
> > > > > Can someone (Dave ?) try the above fix and see if it works ? > > > > > > I'll give it a try later this morning (my time, EST ) and let you know. > > > > Ok - I've tried it out... > > > > I move the initialization of rep->r_mrep to be before the > > tryagain: label, just as the other initializations were... > > > > Unfortunately; I still experience the hang... > > well, ok. The fix above just serves to prevent a race when a request > arrives while nfs_request() proceeds down to sbwait(). > > I am looking into the problem to see what else may be happening > (presumably in the way up when requests are demultiplexed). > > > This problem seems to be particular to readdir() - I'm wondering if > > readdir() is somehow doing an soreceive() without going through nfs_reply(); > > i.e. avoiding the nfs_rcvlock() somehow... > > Can you put a printf() in nfs_receive (and nfs_reply() ) to see what's > going on ? Oh - you should see my messages file - there are now many printf()s scattered around giving me much information. As you may deduce from my recent mail; I've finally deciphered these printf()s to determine that nfs_lookup() is calling nfs_request() while the one from readdirrpc() is still being waited on... If others agree with my analysis, the question becomes what to do about it? - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181651.MAA08022>