Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Apr 2004 20:20:07 -0600
From:      Jon Noack <noackjr@alumni.rice.edu>
To:        wpaul@windriver.com
Cc:        sean@mcneil.com
Subject:   re0 checksum offloading issue (Re: nfs server issues)
Message-ID:  <406E1F57.7000101@alumni.rice.edu>
In-Reply-To: <1080953041.51638.11.camel@server.mcneil.com>
References:  <1080882894.5980.26.camel@server.mcneil.com> <20040402163353.GC6724@dan.emsphone.com> <1080940409.3711.1.camel@server.mcneil.com> <20040402215745.GB49311@dan.emsphone.com> <1080949413.49158.27.camel@server.mcneil.com> <20040403000742.GD49311@dan.emsphone.com> <1080953041.51638.11.camel@server.mcneil.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4/2/2004 6:44 PM, Sean McNeil wrote:
> On Fri, 2004-04-02 at 16:07, Dan Nelson wrote:
>>In the last episode (Apr 02), Sean McNeil said:
>>>On Fri, 2004-04-02 at 13:57, Dan Nelson wrote:
>>>>In the last episode (Apr 02), Sean McNeil said:
>>>>>OK, here is a tcpdump.  It is confusing. It looks like after the
>>>>>first fragment is received it is looking up some bazaar IP
>>>>>address....
>>>>>
>>>>>13:02:57.566952 free.mcneil.com.1360032988 > server.mcneil.com.nfs: 136 readdir fh 1002,54097/7890231 4096 bytes @ 0x000000000 (DF)
>>>>>13:02:57.567266 server.mcneil.com.nfs > free.mcneil.com.1360032988: reply ok 1472 readdir (frag 1645:1480@0+)
>>>>>13:02:57.567268 0.0.0.1 > 0.0.10.7: (frag 1645:4@1480)
>>>>
>>>>Weird.  Is this at the server or the client?
>>>
>>>This is a client-side dump.  Both server and client have MTU of 1500.
>>>
>>>Server side says:
>>>
>>>15:37:44.292564 IP free.mcneil.com.851449566 > server.mcneil.com.nfs: 136 readdir fh 1002,54097/7890231 4096 bytes @ 0x0
>>>15:37:44.292705 IP server.mcneil.com.nfs > free.mcneil.com.851449566: reply ok 1472 readdir
>>>15:37:44.292711 IP server.mcneil.com > free.mcneil.com: udp
>>>
>>>Is there something in a packet that tells rpc/nfs to reassemble with
>>>something other than the source/destination info?
>>
>>Neither RPC or NFS are involved with fragmentation.  That's all done at
>>the UDP level.  I wonder if it's a NIC problem.  Can you try a
>>different card (maybe even a different brand of card if possible)? 
>>another interesting test would be to get a hub and a 3rd machine, then
>>do dumps with the hub on the server's port, and then the client's port. 
>>If you get garbled frags in both places, I'd lean toward a NIC problem
>>on the server.  If your card supports checksum offloading, try
>>disabling it (ifconfig xx0 -rxcsum -txcsum).
> 
> Bingo!  It looks like a problem with checksum offloading:
> 
> 	ifconfig re0 -rxcsum -txcsum
> 
> and now it no longer hangs.  Good call!  The NIC in question is:
> 
> re0: <RealTek 8110S Single-chip Gigabit Ethernet> port 0xa400-0xa4ff mem
> 0xdf004000-0xdf0040ff irq 12 at device 11.0 on pci1
> 
> The extremely odd thing is http, ldap, samba, and many other services
> that go both to the box and are sent out via nat all work fine.  nfs is
> the only protocol I've seen that has an issue.
> 
> I am happy now :)
> 
> Cheers,
> Sean

Bill,
I'm copying you on this in case you (as the original author) can see 
anything wrong with the driver checksum offloading.

Start of thread:
http://lists.freebsd.org/pipermail/freebsd-current/2004-April/024966.html

Jon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?406E1F57.7000101>