From owner-freebsd-bugs Fri Apr 18 14:51:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06430 for bugs-outgoing; Fri, 18 Apr 1997 14:51:35 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA06272 for ; Fri, 18 Apr 1997 14:50:39 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA16998; Fri, 18 Apr 1997 17:50:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 18 Apr 1997 17:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id RAA27092; Fri, 18 Apr 1997 17:09:22 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id RAA08495; Fri, 18 Apr 1997 17:16:06 -0400 (EDT) Date: Fri, 18 Apr 1997 17:16:06 -0400 (EDT) From: Thomas David Rivers Message-Id: <199704182116.RAA08495@lakes.water.net> To: ponds!nlsystems.com!dfr, ponds!lakes.water.net!rivers Subject: Re: kern/3304: NFS V2 readdir hangs Cc: ponds!freefall.freebsd.org!freebsd-bugs Content-Type: text Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - I've got an interesting little bit of info; so I'm answering my own mail... Dave Rivers writes: > > Doug Rabson writes: > > > .. my description deleted .. > > > > > Nope. The lock is done with flags from the struct nfsmount (flagp = > > &rep->r_nmp->nm_flag). > > Oh yes, I see... > > > This is shared by all the requests and nfsnodes on > > the same mountpoint. The code in nfs_reply is supposed to continue > > looping until the reply for myrep is recieved. If any other replies are > > received, they are matched against the list of outstanding requests and > > their owners will notice when they wake up and try to re-get the rcvlock. > > However; the printf()s I've sprinkled around seem to indicate > that the call to nfs_lookup() is getting through the rcvlock() and > doing an sorecieve(). I simply printed the value of "flagp" in nfs_rcvlock() - and, guess what, it was different when called from nfs_lookup() than when called from nfs_readdirrpc()... just a "snippet" or two from my printf()s (of course, it's a little stretch to see here; without the code in front, but I hope it's understandable): This is it's value when we wind down into sbwait(). Apr 18 17:00:54 numb /kernel: nfs_rcvlock(0xf151c7c0) Apr 18 17:00:54 numb /kernel: flagp is 0xf14bb200 Apr 18 17:00:54 numb /kernel: *flagp is 0x2000e Apr 18 17:00:54 numb /kernel: nfs_rcvlock - (at bottom) returning 0 Apr 18 17:00:54 numb /kernel: back from nfs_rcvlock - error is 0 Apr 18 17:00:54 numb /kernel: calling nfs_receive .... Apr 18 17:00:55 numb /kernel: Enter sbwait() Apr 18 17:00:55 numb /kernel: SB_NOINTR is 1 Apr 18 17:00:55 numb /kernel: sb->sb_timeo is 0 Apr 18 17:00:55 numb /kernel: sleeping on 0xf14ba040 Then; we have: Apr 18 17:01:00 numb /kernel: ---- Enter nfs_lookup() -------- Apr 18 17:01:00 numb /kernel: nfs_request() Apr 18 17:01:00 numb /kernel: malloc'd nfsreg = 0xf151c700 ... Apr 18 17:01:01 numb /kernel: nfs_rcvlock(0xf151c700) Apr 18 17:01:01 numb /kernel: flagp is 0xf14b9a00 Apr 18 17:01:01 numb /kernel: *flagp is 0x2000e Apr 18 17:01:01 numb /kernel: nfs_rcvlock - (at bottom) returning 0 Apr 18 17:01:01 numb /kernel: back from nfs_rcvlock - error is 0 Apr 18 17:01:01 numb /kernel: calling nfs_receive So - it would appear that the reason the nfs_rcvlock() is "going through" is that flagp is different... I don't have any really good ideas why... - Dave Rivers -