From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 15:10:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D49516A4CE; Sat, 24 Jan 2004 15:10:37 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB3443D4C; Sat, 24 Jan 2004 15:10:29 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0ONATAF073574; Sat, 24 Jan 2004 15:10:29 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0ONATlo073573; Sat, 24 Jan 2004 15:10:29 -0800 (PST) (envelope-from rizzo) Date: Sat, 24 Jan 2004 15:10:29 -0800 From: Luigi Rizzo To: Robert Watson Message-ID: <20040124151029.A73519@xorpc.icir.org> References: <20040124110508.A71777@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@freebsd.org on Sat, Jan 24, 2004 at 02:12:12PM -0500 cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 23:10:37 -0000 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