Re: [bisect] kernel 2.6.38 regression with root nfs mounting

[Chuck Lever]

On Mar 23, 2011, at 10:30 AM, Belisko Marek wrote:

> On Wed, Mar 23, 2011 at 3:06 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>> 
>> On Mar 23, 2011, at 9:46 AM, Belisko Marek wrote:
>> 
>>> On Wed, Mar 23, 2011 at 2:44 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>>>> 
>>>> What does "rpcinfo -p 10.146.1.21" output look like?  Is NFS over UDP enabled on your server?
>>> program vers proto   port
>>>    100000    2   tcp    111  portmapper
>>>    100000    2   udp    111  portmapper
>>>    100024    1   udp  40517  status
>>>    100024    1   tcp  51397  status
>>>    100021    1   udp  44516  nlockmgr
>>>    100021    3   udp  44516  nlockmgr
>>>    100021    4   udp  44516  nlockmgr
>>>    100021    1   tcp  55152  nlockmgr
>>>    100021    3   tcp  55152  nlockmgr
>>>    100021    4   tcp  55152  nlockmgr
>>>    100003    2   tcp   2049  nfs
>>>    100003    3   tcp   2049  nfs
>>>    100003    4   tcp   2049  nfs
>>>    100227    2   tcp   2049
>>>    100227    3   tcp   2049
>>>    100003    2   udp   2049  nfs
>>>    100003    3   udp   2049  nfs
>>>    100003    4   udp   2049  nfs

The server is advertising NFS over UDP.  Why can't a client access your server via UDP?  What happens if you perform a normal post-boot mount of this file system via UDP?

>>>    100227    2   udp   2049
>>>    100227    3   udp   2049
>>>    100005    1   udp  58278  mountd
>>>    100005    1   tcp  37178  mountd
>>>    100005    2   udp  58278  mountd
>>>    100005    2   tcp  37178  mountd
>>>    100005    3   udp  58278  mountd
>>>    100005    3   tcp  37178  mountd
>> 
>> Can you boot if you specify either the "tcp" or "proto=tcp" NFSROOT mount options?
> When add proto=tcp to bootargs it boot fine
> (....nfsroot=10.146.1.21:/home/open-nandra/rootfs,proto=tcp....).
>> Perhaps a network trace would be probative.  Capture on the server with "tcpdump -s0 -w /tmp/foo ip 10.146.1.199" (untested, but I think you get the idea) while the client is attempting to boot, and post.
> Log is attached in attachment (too big 4.8M). Correct form is: tcpdump
> -s0 -w /tmp/foo host 10.146.1.199

Received.  I should have been clear: Please capture a non-working client boot attempt.  To reduce the size of the attachment, strip the TFTP packets before sending, and please gzip the file.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/