Date: Sat, 24 Jan 2004 15:10:29 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Robert Watson <rwatson@freebsd.org> Cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets Message-ID: <20040124151029.A73519@xorpc.icir.org> In-Reply-To: <Pine.NEB.3.96L.1040124140452.62871G-100000@fledge.watson.org>; from rwatson@freebsd.org on Sat, Jan 24, 2004 at 02:12:12PM -0500 References: <20040124110508.A71777@xorpc.icir.org> <Pine.NEB.3.96L.1040124140452.62871G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 24, 2004 at 02:12:12PM -0500, Robert Watson wrote: ... > > but going this way you have no idea on what the driver does, including > > enabling hw checksums. This looks like a useless test at least for the > > purpose of finding out what is going wrong > > Actually, I'm more curious about whether it's a known errata/misbehavior > for the card that 3Com's drivers work around, or not. The problem could > well be compleely unrelated to hardware checksuming per se -- the > corruption might well be taking place as the buffer is moved from the > card's buffer to the operating system managed buffer. If the NDIS driver > doesn't illustrate the same problem, it tells us that by frobbing > appropriately, this problem can be worked around. It also tells us that > by looking a bit harder at what the driver is doing (i.e., how it frobs > the hardware), we can learn something about the appropriate workaround. yes, but how would you know that, short of reverse engineering the driver, or tracing I/O accesses to the hardware ? It really looks like an overkill effort... I'd rather just try to debug the issue working on an open source driver, or dump the hardware altogether and replace it with something known to work... cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040124151029.A73519>