Re: [BUG?] Maybe NFS bug since 2.6.37 on SPARC64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>  [11140.867895] NFS:   parsing nfs mount option 'retrans=10'

>>  [11140.867946] NFS:   parsing nfs mount option 'timeo=60'
>>  [11140.867996] NFS:   parsing nfs mount option 'nolock'
>>  [11140.868043] NFS:   parsing nfs mount option 
> 'addr=137.226.167.241'
>>  [11140.868106] NFS: MNTPATH: '/srv/nfs/cluster2'
>>  [11140.868142] NFS: sending MNT request for 
> 137.226.167.241:/srv/nfs/cluster2
>>  [11141.912761] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow 
> Control: Rx
>>  [11141.933177] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>  [11143.873095] NFS: failed to create MNT RPC client, status=-65
>>  [11143.873205] NFS: unable to mount server 137.226.167.241, error -65
> 
> You got a different result: -65 is EHOSTUNREACH.  And actually, I would have 
> expected that error from the UDP case as well.
> 

Oh, sorry! I thought it wouldn't have used the option...
Thanks for this hint!

But I've another important fact:
I've tested linux-3.1 and the behaviour is the same as in linux-2.6.39.4 with the difference that eth0 seems to be up when NFS tries to mount NFSROOT. So I see no reason why the kernel can't send the mount request (I see no request in wireshark).

So now I'll enable more debug output in 3.1 and send you the result like I've done it in my last email for 2.6.39.4...
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux