• <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 閱讀(2341) 評論(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.
            2020久久精品亚洲热综合一本| 影音先锋女人AV鲁色资源网久久| 久久精品中文字幕一区| 久久精品久久久久观看99水蜜桃| 99久久这里只精品国产免费| 亚洲国产另类久久久精品小说 | 亚洲av伊人久久综合密臀性色| 综合久久一区二区三区 | 久久精品成人免费观看97| 国产成人精品综合久久久| 久久久精品国产亚洲成人满18免费网站 | 亚洲国产小视频精品久久久三级| 久久久久久青草大香综合精品| 色综合久久中文字幕综合网| 少妇久久久久久被弄高潮| 亚洲精品高清国产一久久| 久久只有这里有精品4| 精品久久无码中文字幕| 国产成人无码精品久久久久免费 | 国产综合久久久久| 伊人久久大香线蕉无码麻豆| 久久久久久综合一区中文字幕| 超级碰碰碰碰97久久久久| 久久99热精品| 无码久久精品国产亚洲Av影片 | 亚洲午夜久久久影院| 国内精品久久久久久麻豆| 久久天堂AV综合合色蜜桃网| 亚洲精品乱码久久久久久蜜桃| 亚洲伊人久久大香线蕉苏妲己| 国内精品综合久久久40p| 精品久久久久久99人妻| 69国产成人综合久久精品| 伊人久久综合精品无码AV专区 | 996久久国产精品线观看| 国内精品九九久久精品| 亚洲国产精品无码久久九九| 国产精品美女久久久免费| 国产精品天天影视久久综合网| 无码人妻精品一区二区三区久久| 久久久精品国产免大香伊|