本人的問題是
板子mount上nfsserver，在nfs server上同時讀寫，有問題。
可以用以下命令測試。詳見最後的鏈接：
time dd if=/dev/zero of=/mnt/nfs/testfile bs=16k count=16384
轉：
http://bigfirebird.javaeye.com/blog/684761
檢查一下主機的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
袁瑞麟：
本人嘗試通過mount -o tcp參數解決，但是速度很慢。