• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Prayer

            在一般中尋求卓越
            posts - 1256, comments - 190, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            not responding, still trying

            Posted on 2009-04-11 12:36 Prayer 閱讀(2339) 評論(3)  編輯 收藏 引用 所屬分類: LINUX/UNIX/AIX

            檢查一下主機的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


            Feedback

            # re: not responding, still trying   回復  更多評論   

            2010-07-15 00:09 by DelorisBooth
            I opine that to receive the <a href="http://bestfinance-blog.com/topics/mortgage-loans">mortgage loans</a> from banks you must have a great reason. But, once I have received a financial loan, because I was willing to buy a house.

            # re: not responding, still trying   回復  更多評論   

            2010-11-09 10:25 by thesis service
            If you want to improve your knowledge connecting with this topic, search for thesis writing service or buy dissertation service and order perfect dissertation subject over there.

            # re: not responding, still trying   回復  更多評論   

            2010-11-09 10:26 by thesis
            Some scholars don’t get know how to see the thesis paper related to this topic. Thence, I should offer your good enough data. But they shoulld get the thesis.
            久久精品国产亚洲欧美| 丁香五月综合久久激情| 无码人妻久久一区二区三区免费| 国产69精品久久久久观看软件| 久久精品中文字幕一区| 国产精品免费久久久久电影网| 国产精品九九久久免费视频 | 狼狼综合久久久久综合网| 亚洲综合精品香蕉久久网| 午夜欧美精品久久久久久久| 精品久久久久久无码专区不卡| 97r久久精品国产99国产精| 999久久久免费国产精品播放| 久久人妻少妇嫩草AV无码蜜桃| 欧美亚洲国产精品久久久久| 99久久精品午夜一区二区| 亚洲婷婷国产精品电影人久久| 久久久久久精品无码人妻| 久久精品无码一区二区日韩AV| 狠狠色狠狠色综合久久| 丁香狠狠色婷婷久久综合| 久久久久亚洲AV无码专区桃色| 亚洲国产欧美国产综合久久| 精品久久人人妻人人做精品| 久久精品国产亚洲AV大全| 亚洲国产精品无码久久一线 | 亚洲国产精品无码久久久久久曰| 日产精品久久久一区二区| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 久久天天躁狠狠躁夜夜avapp| 中文字幕一区二区三区久久网站 | 久久99国产精一区二区三区| 久久精品国产AV一区二区三区| 久久成人永久免费播放| 国产精品久久久久久久久久免费| 东京热TOKYO综合久久精品| 亚洲伊人久久精品影院| 东方aⅴ免费观看久久av| 免费一级欧美大片久久网| 欧美激情精品久久久久久| 欧美精品福利视频一区二区三区久久久精品 |