Date: Mon, 13 May 2002 11:51:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Greenman-Lawrence <dg@root.com>, jamie@tridentmicrosystems.co.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: Broadcom BCM5701 Chipset problems Message-ID: <3CE00B14.E8CA43A8@mindspring.com> References: <20020513115600.A50967@mufuf.trident-uk.co.uk> <3CDFF60C.48A2EA65@mindspring.com> <20020513102526.H72322@nexus.root.com> <200205131758.g4DHwJFj068941@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :>If you aren't using VLAN tagging, you shouldn't care. > : > : No, that is absolutely not correct. The checksum problems happend in many > :situations, depending on the chipset and other factors. The problem that > :resulted in the commit to disable the receive hardware checksum was caused > :by small packets with certain byte patterns, NOT VLAN ENCAPSULATION. > > 100% confirmation here. When Bill Paul was tracking down these issues > on my 2550's they were all operating normally, without any vlan tagging. > > The broadcom chips are horrendously buggy. The phase of the moon is as > likely to cause a problem as anything else. The on-chip checksum code > is especially bad. It's a classic example of rushing a chip into > production and praying that the hardware is flexible enough that > problems can be fixed in software by the driver. This is depressing. The Dell PowerEdge 2550's use the BGE driver (Tigon III). I'm really surprised that the problem exists on the Tigon III. My personal experience with Tigon III's was that the hardware checksumming was working. Maybe my testing was too lax. 8-(. My local copy of the -STABLE source tree leaves BGE_CSUM_FEATURES set on in the driver; is there a change that needs to be MFC'ed to turn these suckers off? I thought this was a Tigon II specific problem, and was specific to the non-Broadcom/Alteon firmware; from if_ti.c: /* * Temporarily disable the checksum offload support for now. * Tests with ftp.freesoftware.com show that after about 12 hours, * the firmware will begin calculating completely bogus TX checksums * and refuse to stop until the interface is reset. Unfortunately, * there isn't enough time to fully debug this before the 4.1 * release, so this will need to stay off for now. */ There's no similar comment in the if_bge.c ... Can you guys elaborate on the problem? Was it on incoming checksums, outgoing checksums, or both? If it was only incoming, could you maybe trust the checksum based on the size of the packet, and unset the precalculated flag on at-risk packets only? I only remember the NetGear and other VLAN tagging/checksum interaction discussion over the Tigon II's in -net. 8-(. Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE00B14.E8CA43A8>