Date: Tue, 21 Mar 2006 15:52:19 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: hme(4) broken on non-sparc64 systems in -current Message-ID: <20060321065219.GB79203@cdnetworks.co.kr> In-Reply-To: <20060321061508.GK31216@uriah.heep.sax.de> References: <20060320211720.GB31216@uriah.heep.sax.de> <20060320235732.GA79203@cdnetworks.co.kr> <20060321061508.GK31216@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 21, 2006 at 07:15:09AM +0100, Joerg Wunsch wrote: > As Pyun YongHyeon wrote: > > > How about backing out rev. 1.46(if_hme.c)? > > > For the same patch sent to bard@OpenBSD I got a positive report > > so it's strange to me though.(brad@OpenBSD reported Rx checksum > > offload breakage on little endian systems.) > > Yes, backing that out helps. I'm not sure what this change was trying > to fix. I've noticed before that tools like ethereal reported the If my memory serve right, the flag variable holds host byte order data. The lower 16bit has a checksum value computed by HME hardware. Since the checksum value should be computed with network byte order I applied htos to the value in order to get correct value. > checksum as invalid but the traffic itself was unaffected. Anyway, as If you see checksum invalid message on Tx traffic it's normal for checksum offloaded NIC. However if you see the checksum error on Rx traffic it's real checksum error. > it was now, the traffic was blocked, so perhaps there's more than one > spot where this needs to be fixed? > Maybe. I have no idea yet. > I'll look a bit further into it tonight. Thanks! > You're welcome. Sorry for the breakge. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060321065219.GB79203>