Return-Path: Received: from glaurung.lavos.net ([69.162.133.92]:49709 "EHLO glaurung.lavos.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794Ab1BJGbq (ORCPT ); Thu, 10 Feb 2011 01:31:46 -0500 Date: Wed, 9 Feb 2011 20:58:55 +0000 From: Brian Downing To: Chuck Lever Cc: deepaksi , Armando VISCONTI , Trond Myklebust , netdev@vger.kernel.org, Linux NFS Mailing List , Shiraz HASHIM , Viresh KUMAR , Peppe CAVALLARO , amitgoel Subject: Re: STMMAC driver: NFS Problem on 2.6.37 Message-ID: <20110209205855.GB6402@glaurung.lavos.net> References: <4D2EC133.7010607@st.com> <2D04CF75-CA68-4BDC-99A3-FA1DD6113602@oracle.com> <4D2F4453.4040400@st.com> <4D301DD1.9070104@st.com> <593F2676-CA62-4D77-90AD-41F2FAF13EB6@oracle.com> <4D3EBA54.4020308@st.com> <20110209200129.GA6402@glaurung.lavos.net> Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote: > Based on your console logs, I see that the working case uses UDP to > contact the server's mountd, but the failing case uses TCP. You can > try explicitly specifying "proto=udp" to force the use of UDP, to test > this theory. This does indeed make it work again for me, thanks! > Meanwhile, the patch description explicitly states that the default > mount option settings have changed. Does it make sense to change the > default behavior of NFSROOT mounts to use UDP again? I don't see > another way to make this process more reliable across NIC > initialization. If this is considered a regression, we can make a > patch for 2.6.38-rc and 2.6.37. I only use nfsroot for development, so I don't have a terribly strong opinion. I would point out though that the default u-boot parameters for nfsrooting a lot of boards will no longer work at this point, so if it's not patched to work again without specifying nfs options I think there should at least be a note in the documentation and possibly a "maybe try proto=udp?" console message on failure. I assume it's not feasable to either wait until the chosen interface's link is ready before trying to mount nfsroot, or retrying TCP-based connections a little bit more aggressively/at all? -bcd