From owner-freebsd-hackers Sun Dec 16 7:28:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 38D3537B416 for ; Sun, 16 Dec 2001 07:28:30 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA16651; Sun, 16 Dec 2001 10:28:21 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id fBGFRuD09584; Sun, 16 Dec 2001 10:27:56 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15388.48508.65545.403221@grasshopper.cs.duke.edu> Date: Sun, 16 Dec 2001 10:27:56 -0500 (EST) To: David Greenman Cc: rsharpe@ns.aus.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Does anyone know if the Broadcom BCM5700 has problems with HW csum? In-Reply-To: <20011215150933.B86349@nexus.root.com> References: <3C1AEA9E.6010502@ns.aus.com> <20011214214118.A30560@Odin.AC.HMC.Edu> <3C1AF362.534BD2F7@mindspring.com> <20011215005739.A84861@nexus.root.com> <20011215031304.N79896@elvis.mu.org> <20011215011045.C84861@nexus.root.com> <3C1B32EB.ACBA8DB@mindspring.com> <20011215135635.A86349@nexus.root.com> <3C1BD22F.F3A52BF4@mindspring.com> <20011215150933.B86349@nexus.root.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Greenman writes: > >David Greenman wrote: > >> >In any case, disabling it is what ClickArray ended up doing, as well, > >> >for the Tigon II, until the firmware could be fixed. > >> > >> We're talking about the Tigon III (bge driver for Broadcom BCM5700/BCM5701). > > > >Crap. Thanks for the info. > > > >Have you manually calculated the checksum on a bad packet to see > >how it's off? > > Yes. It's typically off by 0x1051, but varies depending on the TCP/IP > header contents. Hmm.. Since you've already got the code for calculating the checksum in the driver written, why not use it? Eg, why not pass the csum up & set CSUM_DATA_VALID iff the csum ends up being 0? Are you worried that the firmware will yield false posatives too? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message