From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 11:14:22 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 47AFB16A4CE for ; Sat, 24 Jan 2004 11:14:22 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B0E43D1D for ; Sat, 24 Jan 2004 11:14:20 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0OJCCUd094221; Sat, 24 Jan 2004 14:12:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0OJCCrT094218; Sat, 24 Jan 2004 14:12:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 24 Jan 2004 14:12:12 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20040124110508.A71777@xorpc.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 19:14:22 -0000 On Sat, 24 Jan 2004, Luigi Rizzo wrote: > On Sat, Jan 24, 2004 at 01:38:37PM -0500, Robert Watson wrote: > ... > > (2) Try the NDIS driver with the NDIS-u-lator on FreeBSD 5.x and see if > > that also has the problem. > > 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. If it's a delay/timing issue, it's less likely we can learn something, but if the NDIS driver is simply disabling hardware checksumming for specific chipsets, that's something we should be able to figure out. On the other hand, if the NDIS driver shows the exact same problem, this might not be an issue known to the vendor. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research