• <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 閱讀(2332) 評論(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.
            久久综合国产乱子伦精品免费| 国产亚洲精品美女久久久| 亚洲精品无码久久不卡| 久久SE精品一区二区| 久久婷婷久久一区二区三区| 久久夜色精品国产| 久久ZYZ资源站无码中文动漫| 国产亚洲精久久久久久无码AV| 国产免费久久精品99re丫y| 99re这里只有精品热久久| 欧美大战日韩91综合一区婷婷久久青草| 久久综合九色综合网站| a级毛片无码兔费真人久久| 久久妇女高潮几次MBA| 久久无码国产| 久久伊人精品青青草原高清| 亚洲中文字幕无码久久2017| 久久久久无码中| 久久91精品国产91久久小草| 狠狠色婷婷久久综合频道日韩| 久久精品国产72国产精福利| 国产精品久久久久久久久免费| 中文字幕乱码久久午夜| 国内精品久久久久影院优 | 香蕉久久永久视频| 久久亚洲国产欧洲精品一| 久久久久久国产精品免费无码| 亚洲国产成人乱码精品女人久久久不卡| 国产精品天天影视久久综合网| 久久婷婷五月综合97色一本一本| 亚洲一区精品伊人久久伊人| 久久伊人影视| 中文精品99久久国产| 亚洲伊人久久成综合人影院| 亚洲另类欧美综合久久图片区| 久久亚洲av无码精品浪潮| 日本高清无卡码一区二区久久| 久久精品国产精品亚洲| 欧美午夜A∨大片久久| 欧美伊人久久大香线蕉综合69| 亚洲精品99久久久久中文字幕|