Date: Fri, 15 Jan 2010 15:51:00 -0800 (PST) From: alan bryan <alan.bryan@yahoo.com> To: pyunyh@gmail.com Cc: freebsd-stable@freebsd.org Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0? Message-ID: <709036.53645.qm@web50505.mail.re2.yahoo.com> In-Reply-To: <20100115193235.GH1228@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Fri, 1/15/10, Pyun YongHyeon <pyunyh@gmail.com> wrote:=0A=0A> From: = Pyun YongHyeon <pyunyh@gmail.com>=0A> Subject: Re: General problems with ch= ecksums (txcsum/rxcsum) on FreeBSD 8.0?=0A> To: "alan bryan" <alan.bryan@ya= hoo.com>=0A> Cc: freebsd-stable@freebsd.org=0A> Date: Friday, January 15, 2= 010, 11:32 AM=0A> On Fri, Jan 15, 2010 at 11:12:43AM=0A> -0800, alan bryan = wrote:=0A> > I just read a different thread about problems with=0A> checksu= ms on vge (and nfe in the replies).=0A> > =0A> > I'll just chime in here wi= th some more information - I=0A> have a couple other message threads going = about some weird=0A> high packet volumes on my new FreeBSD 8.0-Release NFS= =0A> server.=A0 I thought it might be an issue with the igb=0A> driver so I= put in a new card using em instead and got the=0A> exact same behavior.=A0= I'm currently sifting through a=0A> tcpdump in wireshark and there are all= sorts of messages in=0A> there about checksums being incorrect - both TCP = and=0A> UDP.=A0 This is for communications between this client=0A> machine = (FreeBSD 7.0-Release) and any of the 8.0 machines I=0A> have.=A0 The packet= s going to non-8.0 machines (at least=0A> so far) appear to be fine.=0A> > = =0A> > I'll defer to those who know more than I about the=0A> networking co= de, but is there perhaps an issue in general=0A> with the checksuming and n= ot specific to one card or driver=0A> - is that even possible?=A0 That's no= w 4 different=0A> drivers all with various checksum problem reports.=0A> > = =0A> > I'm going to be working on this all day today (and=0A> likely over t= he weekend) so if I can help by supplying=0A> information please let me kno= w what you need.=0A> > =0A> =0A> If you are seeing bad checksum reported by= =0A> tcpdump/wireshark for TX=0A> frames on checksum capable controller, it= 's normal. bpf(4)=0A> just=0A> sees TX frames before inserting checksum com= puted by=0A> hardware so=0A> tcpdump/wireshark reports invalid checksum. Yo= u can safely=0A> ignore=0A> that. If you want to verify whether sending hos= t generated=0A> correct=0A> checksum, you should capture the frame on recei= ve side. If=0A> tcpdump/=0A> wireshark reports bad checksummed frame on rec= eived frames=0A> it's=0A> real bad checksummed frame.=0A=0A=0AThanks for th= e help. After looking deeper into this issue today I'm now sure that I'm s= tuck 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.=0A=0ATo try to get mo= re information to act on, I'm going to change my client mount options and s= ee what happens.=0A=0AThanks everyone.=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?709036.53645.qm>