> We tried to upgrade from 2.0.35 to 2.2.5 results:
>
> 2. Strange messages in the log
>
> Apr 6 17:07:14 hur kernel: nsm_mon_unmon: rpc failed, status=-13
Your server is for some reason not allowing access to the rpc.statd
port. Is it running rpc.statd?
> 3. NFS troubles with clients:
>
> Apr 5 15:08:11 aaron kernel: __nfs_fhget: inode 51527361 busy, i_count=2,
> i_nlink=1
> Apr 5 15:08:11 aaron kernel: nfs_free_dentries: found //hreed.lock,
> d_count=0, hashed=1
> Apr 5 15:08:11 aaron kernel: nfs_dentry_delete: //hreed.lock:
> ino=51527361, count=2, nlink=1
This is fine... Just a stale file handle on an unused dentry.
> Apr 5 16:08:02 aaron kernel: nfs: RPC call returned error 111
> Apr 5 16:08:02 aaron kernel: RPC: task of released request still queued!
> Apr 5 16:08:02 aaron kernel: RPC: (task is on xprt_pending)
> Apr 5 16:08:02 aaron kernel: nfs_revalidate_inode: /// getattr failed,
> ino=51526690, error=-111
This is more serious: it indicates that the RPC layer has some
socket-related problems communicating with your host. In principle it
should only occur while your server is rebooting (when the net is up,
but the port unavailable 'cos the server hasn't yet started). If it is
occurring across an active net with a bona-fide live NFS server, I'd
be interested in seeing a tcpdump (please use the '-s 256' option in
order to pick up the NFS header details).
NB: The 'ac' kernel series will probably handle this error in a better
way (it pauses for 5 seconds, then retries the connection).
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/