Overview
I've solved the NFS mount problem on the TiBook.
The first problem was that "portmap" was not running on the TiBook. Once that was started, the NFS mounts completed and returned right away.
This is, however, baffling. When an NFS client does an NFS mount from a remote server, it should be asking the *server* "portmap"/"rpcbind" process for the mountd/NFS RPC service numbers and versions, not the *local* "portmap" process. So, something down in the kernel wanted to talk to "portmap" after the actual mount negotiation completed (see earlier messages), and I don't know why.
But - that alone did not get me out of the woods. Because, once "portmap" was running and the mounts returned right away, actually *accessing* the filesystem hung - in exactly the same way as the mounts! An "ls" would hang, and show the same WCHAN in "ps" as the previously-hung "mount" - down in rpc_execute. So I was really baffled at this point - the "ls" wasn't even completing after 5 minutes, it was totally hung. (But at least it could be ^C/^\'ed out of.)
Then I got lucky.
I found this snippet at linuxdoc.org/HOWTO/NFS-HOWTO/interop.html
So, I changed the (manual) mount parameters to use "rsize=32768,wsize=32768" and now it works. And - it even works mounting filesystems from our NetApp, which isn't a Solaris box.8.6. Solaris 8.6.1. Solaris Servers [...] Solaris servers are especially sensitive to packet size. If you are using a Linux client with a Solaris server, be sure to set rsize and wsize to 32768 at mount time.
Now - don't ask me why (a) this works fine over on the Mac over the Gigabit Ethernet *without* me needing to set rsize and wsize to 32768; and (b) why it also works fine mounting from the NetApp using 32768 (whereas before, it also hung - I used "mipl3" as the test mule for mount testing only because I could snoop the NFS traffic from there).
Anyway, the bottom line is, it works now, I'm happy, we have a nice large phatpipe rsize/wsize ...
This HOWTO is by Greg Earle, MIPL, NASA JPL
