Date: Fri, 18 Apr 1997 17:16:06 -0400 (EDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!nlsystems.com!dfr, ponds!lakes.water.net!rivers Cc: ponds!freefall.freebsd.org!freebsd-bugs Subject: Re: kern/3304: NFS V2 readdir hangs Message-ID: <199704182116.RAA08495@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704182116.RAA08495>