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=
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available
partitions:
1f00 64 mtdblock0 (driver?)
1f01 256 mtdblock1 (driver?)
1f02 2816 mtdblock2 (driver?)
1f03 5056 mtdblock3 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
Backtrace:
[<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
(dump_stack+0x18/0x1c)
r7:c7b5b000 r6:00000000 r5:c7b5b015 r4:c04296b8
[<c003721c>] (dump_stack+0x0/0x1c) from [<c004ebf8>] (panic+0x60/0x180)
[<c004eb98>] (panic+0x0/0x180) from [<c0009114>]
(mount_block_root+0x1d4/0x214)
r3:00000000 r2:00000001 r1:c782bf50 r0:c0394851
[<c0008f40>] (mount_block_root+0x0/0x214) from [<c00091fc>]
(mount_root+0xa8/0xc8)
[<c0009154>] (mount_root+0x0/0xc8) from [<c0009388>]
(prepare_namespace+0x16c/0x1d0)
r4:c04288c0
[<c000921c>] (prepare_namespace+0x0/0x1d0) from [<c0008904>]
(kernel_init+0x1cc/0x220)
r5:c0402048 r4:c0428860
[<c0008738>] (kernel_init+0x0/0x220) from [<c00522a8>] (do_exit+0x0/0x5e0)
r7:00000013 r6:c00522a8 r5:c0008738 r4:00000000
CPU0: stopping
Backtrace:
[<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
(dump_stack+0x18/0x1c)
r7:c0405484 r6:00000406 r5:00000000 r4:00000000
[<c003721c>] (dump_stack+0x0/0x1c) from [<c002d334>] (do_IPI+0xb4/0x124)
[<c002d280>] (do_IPI+0x0/0x124) from [<c0032bb4>] (__irq_svc+0x34/0xc0)
Exception stack(0xc03f3f50 to 0xc03f3f98)
3f40: c0402048 00000000 c03f3f98
00000000
3f60: c03f2000 c04288dc c0027290 c0405484 000258e8 411fc091 00000000
c03f3fa4
3f80: c03f3fa8 c03f3f98 c0034a24 c0034a28 60000013 ffffffff
r5:fc800100 r4:ffffffff
[<c00349fc>] (default_idle+0x0/0x30) from [<c0034874>] (cpu_idle+0x80/0xc0)
[<c00347f4>] (cpu_idle+0x0/0xc0) from [<c030602c>] (rest_init+0x64/0x7c)
r5:c04288dc r4:c04020b0
[<c0305fc8>] (rest_init+0x0/0x7c) from [<c0008bd4>]
(start_kernel+0x27c/0x2d8)
[<c0008958>] (start_kernel+0x0/0x2d8) from [<00008038>] (0x8038)
r5:c0401fac r4:10c5387d
I have tried the same over latest source picked from linus tree,
4162cf64973df51fc885825bc9ca4d055891c49f
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
We are using version 3 of the NFs protocol in kernel's NFS client.
Regards
Deepak
ST Microelectronics
.
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?
>
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
On Jan 14, 2011, at 4:56 AM, deepaksi wrote:
> 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.
Have you tried any kernel versions between 2.6.32 and 2.6.37? I made significant changes in 2.6.36, so it would be helpful to know when this stopped working.
Also, in 2.6.36, I added a new debugging feature for NFSROOT. See "nfsrootdebug" description in Documentation/filesystems/nfs/nfsroot.txt.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
> 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:
>
Also no problem on my side with the Kernel 2.6.32 plus
the latest device driver from net-2.6.
Peppe
> 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=
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option; here are the available
> partitions:
> 1f00 64 mtdblock0 (driver?)
> 1f01 256 mtdblock1 (driver?)
> 1f02 2816 mtdblock2 (driver?)
> 1f03 5056 mtdblock3 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c7b5b000 r6:00000000 r5:c7b5b015 r4:c04296b8
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c004ebf8>] (panic+0x60/0x180)
> [<c004eb98>] (panic+0x0/0x180) from [<c0009114>]
> (mount_block_root+0x1d4/0x214)
> r3:00000000 r2:00000001 r1:c782bf50 r0:c0394851
> [<c0008f40>] (mount_block_root+0x0/0x214) from [<c00091fc>]
> (mount_root+0xa8/0xc8)
> [<c0009154>] (mount_root+0x0/0xc8) from [<c0009388>]
> (prepare_namespace+0x16c/0x1d0)
> r4:c04288c0
> [<c000921c>] (prepare_namespace+0x0/0x1d0) from [<c0008904>]
> (kernel_init+0x1cc/0x220)
> r5:c0402048 r4:c0428860
> [<c0008738>] (kernel_init+0x0/0x220) from [<c00522a8>] (do_exit+0x0/0x5e0)
> r7:00000013 r6:c00522a8 r5:c0008738 r4:00000000
> CPU0: stopping
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c0405484 r6:00000406 r5:00000000 r4:00000000
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c002d334>] (do_IPI+0xb4/0x124)
> [<c002d280>] (do_IPI+0x0/0x124) from [<c0032bb4>] (__irq_svc+0x34/0xc0)
> Exception stack(0xc03f3f50 to 0xc03f3f98)
> 3f40: c0402048 00000000 c03f3f98
> 00000000
> 3f60: c03f2000 c04288dc c0027290 c0405484 000258e8 411fc091 00000000
> c03f3fa4
> 3f80: c03f3fa8 c03f3f98 c0034a24 c0034a28 60000013 ffffffff
> r5:fc800100 r4:ffffffff
> [<c00349fc>] (default_idle+0x0/0x30) from [<c0034874>]
> (cpu_idle+0x80/0xc0)
> [<c00347f4>] (cpu_idle+0x0/0xc0) from [<c030602c>] (rest_init+0x64/0x7c)
> r5:c04288dc r4:c04020b0
> [<c0305fc8>] (rest_init+0x0/0x7c) from [<c0008bd4>]
> (start_kernel+0x27c/0x2d8)
> [<c0008958>] (start_kernel+0x0/0x2d8) from [<00008038>] (0x8038)
> r5:c0401fac r4:10c5387d
>
> I have tried the same over latest source picked from linus tree,
> 4162cf64973df51fc885825bc9ca4d055891c49f
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>
> We are using version 3 of the NFs protocol in kernel's NFS client.
>
>
> Regards
> Deepak
> ST Microelectronics
>
> .
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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?
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or unknown-block(2,0)
> Please append a correct "root=" boot option; here are the available
> partitions:
> 1f00 64 mtdblock0 (driver?)
> 1f01 256 mtdblock1 (driver?)
> 1f02 2816 mtdblock2 (driver?)
> 1f03 5056 mtdblock3 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c7b5b000 r6:00000000 r5:c7b5b015 r4:c04296b8
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c004ebf8>] (panic+0x60/0x180)
> [<c004eb98>] (panic+0x0/0x180) from [<c0009114>]
> (mount_block_root+0x1d4/0x214)
> r3:00000000 r2:00000001 r1:c782bf50 r0:c0394851
> [<c0008f40>] (mount_block_root+0x0/0x214) from [<c00091fc>]
> (mount_root+0xa8/0xc8)
> [<c0009154>] (mount_root+0x0/0xc8) from [<c0009388>]
> (prepare_namespace+0x16c/0x1d0)
> r4:c04288c0
> [<c000921c>] (prepare_namespace+0x0/0x1d0) from [<c0008904>]
> (kernel_init+0x1cc/0x220)
> r5:c0402048 r4:c0428860
> [<c0008738>] (kernel_init+0x0/0x220) from [<c00522a8>] (do_exit+0x0/0x5e0)
> r7:00000013 r6:c00522a8 r5:c0008738 r4:00000000
> CPU0: stopping
> Backtrace:
> [<c00370f0>] (dump_backtrace+0x0/0x110) from [<c0037234>]
> (dump_stack+0x18/0x1c)
> r7:c0405484 r6:00000406 r5:00000000 r4:00000000
> [<c003721c>] (dump_stack+0x0/0x1c) from [<c002d334>] (do_IPI+0xb4/0x124)
> [<c002d280>] (do_IPI+0x0/0x124) from [<c0032bb4>] (__irq_svc+0x34/0xc0)
> Exception stack(0xc03f3f50 to 0xc03f3f98)
> 3f40: c0402048 00000000 c03f3f98
> 00000000
> 3f60: c03f2000 c04288dc c0027290 c0405484 000258e8 411fc091 00000000
> c03f3fa4
> 3f80: c03f3fa8 c03f3f98 c0034a24 c0034a28 60000013 ffffffff
> r5:fc800100 r4:ffffffff
> [<c00349fc>] (default_idle+0x0/0x30) from [<c0034874>] (cpu_idle+0x80/0xc0)
> [<c00347f4>] (cpu_idle+0x0/0xc0) from [<c030602c>] (rest_init+0x64/0x7c)
> r5:c04288dc r4:c04020b0
> [<c0305fc8>] (rest_init+0x0/0x7c) from [<c0008bd4>]
> (start_kernel+0x27c/0x2d8)
> [<c0008958>] (start_kernel+0x0/0x2d8) from [<00008038>] (0x8038)
> r5:c0401fac r4:10c5387d
>
> I have tried the same over latest source picked from linus tree,
> 4162cf64973df51fc885825bc9ca4d055891c49f
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
>
> We are using version 3 of the NFs protocol in kernel's NFS client.
>
>
> Regards
> Deepak
> ST Microelectronics
>
> .
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]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
> .
>
>
On Feb 24, 2011, at 5:36 AM, Shiraz Hashim wrote:
> On Thu, Feb 10, 2011 at 05:26:16AM +0800, Chuck Lever wrote:
>>
>> On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:
>>
>>> 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?
>>
>> Our goal is to use the same mount logic for both normal user
>> space mounts and for NFSROOT (that was the purpose of the patch
>> series this particular patch comes from). It's
>> exceptionally difficult to add a special case for retrying TCP
>> connections here, as that would change the behavior of user
>> space mounts, which often want to fail quickly, and don't need
>> to worry about NIC initialization.
>>
>> Sounds like the right thing to do is restore the default UDP behavior. I'll cook up a patch.
>
> Is there some patch available for this now.
Yes, it was posted a couple of weeks ago (sorry, I don't have an exact reference). I will ping Trond again about getting this upstream.
> There is one more observation (on 2.6.37), when I pass
> nfsroot=$(ip):$(rootpath),udp , then it works fine.
> If I pass proto=udp then it doesn't work. Is there any difference
> between the two methods ?
It may be that proto=udp has an effect only on the transport used for NFS requests, but not for the MNT request. "udp" means "proto=udp,mountproto=udp."
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
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
On Thu, Feb 10, 2011 at 05:26:16AM +0800, Chuck Lever wrote:
>
> On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:
>
> > 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?
>
> Our goal is to use the same mount logic for both normal user
> space mounts and for NFSROOT (that was the purpose of the patch
> series this particular patch comes from). It's
> exceptionally difficult to add a special case for retrying TCP
> connections here, as that would change the behavior of user
> space mounts, which often want to fail quickly, and don't need
> to worry about NIC initialization.
>
> Sounds like the right thing to do is restore the default UDP behavior. I'll cook up a patch.
Is there some patch available for this now.
There is one more observation (on 2.6.37), when I pass
nfsroot=$(ip):$(rootpath),udp , then it works fine.
If I pass proto=udp then it doesn't work. Is there any difference
between the two methods ?
--
regards
Shiraz
On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:
> 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?
Our goal is to use the same mount logic for both normal user space mounts and for NFSROOT (that was the purpose of the patch series this particular patch comes from). It's exceptionally difficult to add a special case for retrying TCP connections here, as that would change the behavior of user space mounts, which often want to fail quickly, and don't need to worry about NIC initialization.
Sounds like the right thing to do is restore the default UDP behavior. I'll cook up a patch.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com