General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?

[alan bryan]

--- On Fri, 1/15/10, Pyun YongHyeon <pyunyh at gmail.com> wrote:

> From: Pyun YongHyeon <pyunyh at gmail.com>
> Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
> To: "alan bryan" <alan.bryan at yahoo.com>
> Cc: freebsd-stable at freebsd.org
> Date: Friday, January 15, 2010, 11:32 AM
> On Fri, Jan 15, 2010 at 11:12:43AM
> -0800, alan bryan wrote:
> > I just read a different thread about problems with
> checksums on vge (and nfe in the replies).
> > 
> > I'll just chime in here with some more information - I
> have a couple other message threads going about some weird
> high packet volumes on my new FreeBSD 8.0-Release NFS
> server.  I thought it might be an issue with the igb
> driver so I put in a new card using em instead and got the
> exact same behavior.  I'm currently sifting through a
> tcpdump in wireshark and there are all sorts of messages in
> there about checksums being incorrect - both TCP and
> UDP.  This is for communications between this client
> machine (FreeBSD 7.0-Release) and any of the 8.0 machines I
> have.  The packets going to non-8.0 machines (at least
> so far) appear to be fine.
> > 
> > I'll defer to those who know more than I about the
> networking code, but is there perhaps an issue in general
> with the checksuming and not specific to one card or driver
> - is that even possible?  That's now 4 different
> drivers all with various checksum problem reports.
> > 
> > I'm going to be working on this all day today (and
> likely over the weekend) so if I can help by supplying
> information please let me know what you need.
> > 
> 
> If you are seeing bad checksum reported by
> tcpdump/wireshark for TX
> frames on checksum capable controller, it's normal. bpf(4)
> just
> sees TX frames before inserting checksum computed by
> hardware so
> tcpdump/wireshark reports invalid checksum. You can safely
> ignore
> that. If you want to verify whether sending host generated
> correct
> checksum, you should capture the frame on receive side. If
> tcpdump/
> wireshark reports bad checksummed frame on received frames
> it's
> real bad checksummed frame.


Thanks for the help.  After looking deeper into this issue today I'm now sure that I'm stuck in some NFS write/fail/retry loop.  I'm still not sure if the trigger to get to that state is NFS, ZFS, or networking code.

To try to get more information to act on, I'm going to change my client mount options and see what happens.

Thanks everyone.