All of lore.kernel.org
 help / color / mirror / Atom feed
From: deepaksi <deepak.sikri@st.com>
To: Armando VISCONTI <armando.visconti@st.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	"Trond.Myklebust@netapp.com" <Trond.Myklebust@netapp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	Shiraz HASHIM <shiraz.hashim@st.com>,
	Viresh KUMAR <viresh.kumar@st.com>,
	Peppe CAVALLARO <peppe.cavallaro@st.com>,
	Amit GOEL <amit.goel@st.com>
Subject: Re: STMMAC driver: NFS Problem on 2.6.37
Date: Fri, 14 Jan 2011 15:26:33 +0530	[thread overview]
Message-ID: <4D301DD1.9070104@st.com> (raw)
In-Reply-To: <4D2F4453.4040400@st.com>

Hi All,

On 1/13/2011 11:58 PM, Armando VISCONTI wrote:
> Chuck Lever wrote:
>   
>> On Jan 13, 2011, at 4:09 AM, deepaksi wrote:
>>
>>   
>>     
>>> Hi
>>>
>>> I am facing a problem related to nfs boot, while using the stmmac driver
>>> ported on 2.6.37 kernel. When we use a JFFS2 file system and mount the kernel,
>>> the network driver works fine.
>>>
>>> I have been following the mailing list and could find some issues with NFS 
>>> on 2.6.37 but I am not too sure whether the kernel crash I am getting is 
>>> related to that.
>>>
>>> The driver worked fine on 2.6.32 kernel, but while booting the 2.6.37
>>> kernel I get the following log messages:
>>>
>>> stmmac: Rx Checksum Offload Engine supported
>>>        TX Checksum insertion supported
>>> IP-Config: Complete:
>>>     device=eth0, addr=192.168.1.10, mask=255.255.255.0, gw=255.255.255.255,
>>>     host=192.168.1.10, domain=, nis-domain=(none),
>>>     bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
>>>     
>>>       
>> Why is rootpath left undefined?
>>   
>>     
>   
Even with dhcp server, we get the same log for rootpath. It never
appears over there.

> Yes, Chuck.
> Good catch.
>
> Deepak,
> Can you possibly verify  your bootargs?
>
> I  see exactly your same problem with kernel 2.6.32 (rc6.3) on my
> board, where the bootargs is defined like this:
>
> bootargs=console=ttyAMA0,115200 mem=128M root=/dev/nfs 
> ip=192.168.1.10:192.168.1
> .1:192.168.1.1:255.255.255.0 nfsroot=192.168.1.1:/home/guest/armv7/target
>
> In fact, rootpath is undefined also in my case...
>
> But if I get the network info from my DHCP server the system is booting 
> correctly.
> (i.e. console=ttyAMA0,115200 mem=128M root=/dev/nfs ip=dhcp)
>
> So, why do we have rootpath undefined in our bootargs?
> I guess we screwed up something someway...
>
> Let's see it tomorrow.
>
> Ciao,
> Arm
>
>
>
>   
The nfs work fine when you use the dhcp server, but still it is a
totally different proposition. The problem comes when we assign a static
IP in the bootargs, and then try to boot the system using NFS. here is
the bootargs setting at the u-boot.

bootargs = console=ttyAMA0,115200 mem=128M root=/dev/nfs
nfsroot=192.168.1.1:/opt/STM/STLinux-2.3/devkit/arm/target
ip=192.168.1.10:192.168.1.1:192.168.1.1:255.255.255.0::eth0

These settings have been working fine for earlier kernels. The tcp dump
while doing the nfs boot is quite different between the 2.6.32 and
2.6.37 kernels.



Regards
Deepak



> .
>
>   


  reply	other threads:[~2011-01-14  9:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-13  9:09 STMMAC driver: NFS Problem on 2.6.37 deepaksi
2011-01-13  9:09 ` deepaksi
2011-01-13 11:48 ` Peppe CAVALLARO
2011-01-13 11:48   ` Peppe CAVALLARO
2011-01-13 15:07 ` Chuck Lever
2011-01-13 15:07   ` Chuck Lever
2011-01-13 18:28   ` Armando Visconti
2011-01-13 18:28     ` Armando Visconti
2011-01-14  9:56     ` deepaksi [this message]
2011-01-14 15:35       ` Chuck Lever
2011-01-14 15:35         ` Chuck Lever
     [not found]         ` <4D3EBA54.4020308@st.com>
2011-01-25 18:04           ` Chuck Lever
2011-01-25 18:04             ` Chuck Lever
2011-01-28 12:43             ` Shiraz Hashim
2011-01-28 12:43               ` Shiraz Hashim
2011-01-28 16:58               ` Chuck Lever
2011-02-09 20:01             ` Brian Downing
2011-02-09 20:12               ` Chuck Lever
2011-02-09 20:12                 ` Chuck Lever
2011-02-09 20:58                 ` Brian Downing
2011-02-09 21:26                   ` Chuck Lever
2011-02-09 21:26                     ` Chuck Lever
2011-02-24 13:36                     ` Shiraz Hashim
2011-02-24 18:33                       ` Chuck Lever
2011-02-24 18:33                         ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D301DD1.9070104@st.com \
    --to=deepak.sikri@st.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=amit.goel@st.com \
    --cc=armando.visconti@st.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=shiraz.hashim@st.com \
    --cc=viresh.kumar@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.