Nfs:server is not responding,still trying causes and solutions

Nfs:server is not responding,still trying causes and solutions

Information One:

After transplanting the cs89x0, we have been confronted with the following question: Nfs:server 192.168. 10.1 Not Respondingnfs:server 192.168. 10.1 Not Respondingnfs:server 192.168. 10.1 OK ... The embedded system has to go through a lot of attempts to hang up for a long time. Initial suspicion is the problem of NFS configuration, and later speculation may be due to cs8900a packet loss caused by serious. Find in 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. 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 a overloaded server), and is throttling back the number of concurrent outstanding R Equests in a attempt to lighten the load. Some Possible causes: * Network congestion * Overloaded server * Packets (input or output) dropped by a bad NIC or driver. ... According to the above view, there are 3 reasons for NFS not responding, namely network congestion, server overload, and network card loss packet. In our experimental system, embedded system and host is directly connected, and the basic server in no-load situation, so should not be the first two kinds of cases, so it is likely that the embedded system NIC packet loss caused by serious. In the target machine, with Ifconfig looked at, it is really serious loss of packets. That's probably the problem. Another unexpected discovery is that in the query lost Packet is, with tcpdump observed that NFS uses UDP protocol. So I guess,Will there be some improvement with TCP? Then there is another problem, how to specify the Parameters for NFS Mounts when NFS is the root file system. With the problem, tracked the FS/NFS/NFSROOT.C code and found that when NFS was the root file system, parameters could be written directly after "nfsroot=", with each parameter separated by commas, such as: Nfsroot=192.168.10.1:/rootfs,proto =tcp,nfsvers=3,nolock This allows you to specify that NFS uses the TCP protocol. After the reboot found that not even the error of not responding, all feel more normal. However, the CS8900A packet loss phenomenon still exists. Therefore, the use of TCP is only a feasible solution, but eventually have to solve the problem of network card packet loss. Data two:

Today, with the Development Board through NFS Mount host, want to copy some data from the host, but unexpectedly appears: Nfs:server is not responding,still trying, I use the friendly arm of mini2440, The operating system is using Ubuntu8.04.
I thought it was an NFS malfunction, but Google found out it was not NFS, but because the data was too large to cause packet loss.
NFS's default transport protocol is UDP, while PC and embedded system through UPD interaction, there will be serious network card packet loss phenomenon. The solution available is to switch to the TCP protocol on the client, using the following command,


Mount-t nfs-o intr,nolock,rsize=1024,wsize=1024 192.168.0.121:/host NFS Directory/mount Path