Well, I think it wasn't an NFS problem after all but rather a problem 
with the driver for the network card. We were using the old "gm" driver 
when we ran into this problem. A few hours ago I tried swiching over to 
the newer "gem" driver and the NFS problem seemed to disappear. But the 
gem driver has some performance issues on our hardware when we try to 
run 100baseTX full-duplex (UDP works very well but TCP hardly works at 
all). So I ended up putting in some extra 3Com-cards into the two Macs 
and now everything seem to work just fine. So I'm hoping the NFS problem 
was just a symptom of the old gm driver (or the network card it self) 
not working very well.

Thanks anyway for trying to reproduce it for me.

/Erik


David Laight wrote:

>>(It would be interesting to see if someone could reproduce this, maybe 
>>on some other arch than macppc.)
>>    
>>
>
>I don't have a problem with your file from a solaris 8 sparc
>server to netbsd 1.6D i386 client.
>Obviously the IP addresses are slightly different though, but the
>ethernet packets look much the same.
>
>I'm using NFSv3 (according to snoop), the file handle (from solaris)
>is 0080000700000002000A0000000040D115CE81EC000A0000000000024D201835
>which could be considerably different from the bsd/linux one.
>
>You may have to track this down the hard way!
>Read the NFS source and use DDB to put breakpoints on some
>likely entry points...
>
>You might find that the kernel stack of the 'stuck' process
>could give a hint as to the deadlock.
>
>	David
>
>  
>