首页 > 代码库 > 在开发板Linux上挂载"驱动"挂载不成功,出现提示server 172.27.52.100 not responding, still trying

在开发板Linux上挂载"驱动"挂载不成功,出现提示server 172.27.52.100 not responding, still trying

1.在开发板具体操作步骤如下:
 
1.1 :设置IP
ifconfig eth0 172.27.52.200
 
1.2 :ping通 虚拟机Linux 主机Linux
ping XXX.XXX.XXX.XXX
 
 
1.3.挂接
mount -t nfs -o nolock  XXX.XXX.XXX.XXX:/work/nfs_root/first_fs  /mnt
// 例如:mount -t nfs -o nolock  172.27.52.100:/work/nfs_root/first_fs  /mnt 
//主机LinuxIP为:172.27.52.100
 
1.4.查看
ls /mnt
 
1.5.加载驱动
insmod  XXX.ko
 
错误提示(而且开发板在终端(串口)的输入/输出都没有反应了):
 server 172.27.52.100 not responding, still trying
 
 
 


 
 
2.报错信息: nfs: server 172.27.52.100 not responding, still trying
 
3.在网上找了下资料.
还是没解决,准备贴出来慢慢解决!!!
 
4.网上找的一篇文章觉得还可以,先贴出来
 

检查一下主机的NFS服务是否正常工作,可以重启一下nfs服务:sudo /etc/init.d/portmap restart 
要是还不行的话,重新安装一遍nfs服务试试 

在移植cs89x0后,就一直碰到如下这个问题: 


nfs: server 192.168.10.1 not responding 

nfs: server 192.168.10.1 not responding 

nfs: server 192.168.10.1 OK 

…… 


嵌入式系统要经过很多次很长时间的尝试才能挂上。初步怀疑是NFS配置的问题,后来猜测可能是由于cs8900a丢包严重造成的。 


在nfs faq找到: 


kernel: nfs: server server.domain.name not responding, still trying 
kernel: nfs: task 10754 can‘t get a request slot 
kernel: nfs: server server.domain.name OK 

A. The "can‘t get a request slot" message means that the client-side RPC code has detected a lot of timeouts (perhaps due to network congestion, perhaps due to an overloaded server), and is throttling back the number of concurrent outstanding requests in an attempt to lighten the load. Some possible causes: 

* Network congestion 
* Overloaded server 
* Packets (input or output) dropped by a bad NIC or driver.... 


根据上述观点,造成NFS没有回应的原因有3个,分别为网络拥塞、服务器过载和网卡丢包。 

在我们的实验系统中,嵌入式系统和宿主机是直连的,而且服务器的基本处于空载的情形,所以不应该是前面两种情况,所以很可能是嵌入式系统网卡丢包严重引起的。 


在目标机器中,用ifconfig看了一下,确实丢包比较严重。很可能就是这个问题了。 


另一个意外的发现是,在查询丢包是,用tcpdump观察到nfs使用的是UDP协议。于是猜想,用TCP会不会有所改善? 

       接着就是另一个问题,如何在nfs作为根文件系统时,指定nfs挂载的参数? 

带着问题,跟踪了fs/nfs/nfsroot.c的代码,发现在nfs作为根文件系统时,参数可以直接写在“nfsroot=”后面,每个参数用逗号隔开,如: 

nfsroot=192.168.10.1:/rootfs,proto=tcp,nfsvers=3,nolock 

这样就可以指定nfs使用tcp协议。 


重启后发现,竟然不再出现not responding的错误,一切感觉较为正常。 

不过,cs8900a丢包现象依然存在。所以,使用tcp只是一个可行的解决办法,但最终还得解决网卡的丢包问题。 



我在arm上通过NFS共享文件时出现下面的错误提示 
nfs:server is not responding,still trying 

原因分析:NFS 的默认传输协议是 UDP,而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。 

解决方法:在客户端改用TCP协议,使用下面的命令, 
#mount -t nfs -o nolock -o tcp 192.168.1.161:/opt /opt 



问题三 NFS:server not responing ,still trying 
文章出处:http://www.diybl.com/course/6_system/linux/Linuxjs/2008716/133207.html 
在目标板上通过NFS复制PC机上较大文件到目标板上的时候遇到的问题: 
nfs: server *** not responding, still trying 

修改方法: 
nfs mount时候出现的NFS崩溃,按照以下的方式mount 
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client 


问题原因: 
Mandag 27 november 2006 20:12 skrev Verner Kj?rsgaard: 
> Mandag 27 november 2006 19:33 skrev John P. New: 
> > Verner, 
> > 
> > This is a problem with NFS and 2.6 kernels, fast server NICs and 
> > comparatively slower client NICs. This will show up when the server has 
> > a 1000Mb card and the client a 100Mb, or when the server has a 100Mb 
> > card and the client a 10Mb. 
> > 
> > Essentially, you have to pass some options to the kernel on terminal 
> > boot, and this varies depending on whether you are using etherboot or 
> > PXE. 
> > 
> > See 
> > http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding 
> > for a deeper explanation of the problem and the cure. 
//注:原因是server机和目标机网卡传输速率冲突,使得目标机需要大量时间复制大量数据包,其实如果目标机的网卡速率够大,则不用分那么多包,也不会冲突。 


附 问题四:在测试时,“./progressbar -qws”后出现如Q3一样的提示 ,按Q3来处理。 
以上参考了一些 “ 快乐的天空”的经验,他的网页是: 
http://blog.chinaunix.net/u2/67519/showart_677885.html 
他的 
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /host 
应该改成 
mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir /client 
文章出处:http://www.diybl.com/course/6_system/linux/Linuxjs/2008716/133207.html

 

 

 

======================================================================================韦东山给出了正确答案======================================================================================

1.在 <开发板>挂接 虚拟机Linux目录时, 在开发板执行命令:

mount -t nfs -o nolock,vers=2  172.27.52.100:/work/nfs_root/first_fs  /mnt 

而不是:

mount -t nfs -o nolock  172.27.52.100:/work/nfs_root/first_fs  /mnt 

 

##注释: 虚拟机Linux的IP: 172.27.52.100   开发板Linux的IP: 172.27.52.200

 

多加了一个,vers=2,但是不知道具体什么原因(由于对mount命令,以及对NFS不熟悉导致,需要恶补);

韦东山的答案是:选择NFS协议的版本

 

2.再来试一下,看一下是否解决前面的

# mount -t nfs -o nolock,vers=2  172.27.52.100:/work/nfs_root/first_fs  /mnt

# insmod /mnt/first_drv.ko 

# lsmod

Module                  Size  Used by    Not tainted

first_drv               2484  0 

 

PS:驱动成功加载,很多问题都是因为没有经验,而导致新手弄几天,都找不到答案!

 

3.下面我们该做的事情应该是找出原因,具体怎么找,得靠大家了,可以在<内核目录>下使用

grep "XXXXXX" * -nR 

命令来搜索有用的信息。

 

4.在/work/system/linux-2.6.22.6 目录下输入:  grep "vers=2" * -nR

打印出如下信息:

fs/nfs/nfsroot.c:153:   {Opt_v2, "nfsvers=2"},

,那么我们跟踪到这个文件去看一下

进入/work/system/linux-2.6.22.6/fs/nfs$目录:

sudo vi nfsroot.c  就可以找到我们需要信息!