• <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.
            精品熟女少妇AV免费久久| 国产成人无码精品久久久久免费| 国产女人aaa级久久久级| 久久国产免费| 少妇久久久久久被弄高潮| 久久亚洲欧美国产精品| 99久久国产综合精品网成人影院| 久久精品国产一区二区电影| 久久夜色精品国产噜噜亚洲a| 久久久久久免费一区二区三区| 亚洲狠狠综合久久| 国内精品久久久久影院薰衣草| 国产成人精品久久综合| 久久亚洲精品国产精品婷婷| 久久国产精品成人免费| 久久精品国产男包| 国产福利电影一区二区三区,免费久久久久久久精 | 久久99热精品| 久久精品国产亚洲av麻豆蜜芽| 久久综合中文字幕| 久久av无码专区亚洲av桃花岛| 久久久久97国产精华液好用吗| 亚洲国产美女精品久久久久∴| 精品久久久久国产免费| 精品无码久久久久国产| 一本色道久久综合| 国产亚洲色婷婷久久99精品91| 精品久久久久久亚洲精品 | 久久伊人精品青青草原高清| 久久亚洲私人国产精品vA| 狠狠色婷婷久久综合频道日韩 | 久久er国产精品免费观看2| 久久久久高潮毛片免费全部播放 | 99久久国产亚洲综合精品| 久久久WWW免费人成精品| 日韩精品久久久久久| 国产精品久久久久久搜索| 99久久久精品| 久久精品国产亚洲沈樵| 国产AV影片久久久久久| 国产99久久久国产精免费|