On Wed, Apr 28, 2010 at 04:24:23PM -0400, Trond Myklebust wrote:
> On Wed, 2010-04-28 at 15:17 -0400, Robert Henney wrote: 

> > /etc/exports on the server, possibly bogus although the server never
> > complains and still probably shouldn't trigger a NULL dereference in 
> > the client:
> >   /stow *(ro,fsid=0,crossmnt,no_subtree_check)
> >   /stow -mp,ro,all_squash,async,no_subtree_check \
> >     199.125.85.51  \
> >     199.125.85.134 \
> >     66.55.209.223
> 
> You probably want to add at least a 'fsid=0' option to that second line.
>
> > /etc/fstab on the client:
> >   199.125.85.39:/stow /stow nfs4 noatime
> 
> Should be
> 
> 199.125.85.39:/ /stow nfs4

if I correct both of the above as you say, then it works.  :)

I should mention though that occasionally when reproducing the bug on 
the client it caused the server kernel (debian lenny
linux-image-2.6.26-2-686) to report its own kernel bug and nfsd on the
server became hosed and unusable for all clients until the server was
rebooted.  kern.log output attached.

since I can only reproduce the kernel bugs using a "wrong" exports
file, I'm not sure how critical they are anymore.

> > the mount command never outputs but has a return code of 2 and the mount
> > is not successful.
> 
> That looks like a stack overflow to me, but it's hard to tell.
> 
> What happens if you do
> 
> echo 1025 > /proc/sys/sunrpc/nfs_debug
> 
> prior to trying the mount?

the client becomes slow enough to be unusable after the value of nfs_debug
is changed to 1025, which is probably due to it being a diskless client.  
although the root filesystem is not the mount causing the issue, I can
try and get a dedicated test machine set up soon to aid further testing.