Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 May 2002 12:55:38 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        David Greenman-Lawrence <dg@root.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, jamie@tridentmicrosystems.co.uk, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Broadcom BCM5701 Chipset problems
Message-ID:  <3CE01A3A.AAB85F64@mindspring.com>
References:  <20020513115600.A50967@mufuf.trident-uk.co.uk> <3CDFF60C.48A2EA65@mindspring.com> <20020513102526.H72322@nexus.root.com> <200205131758.g4DHwJFj068941@apollo.backplane.com> <3CE00B14.E8CA43A8@mindspring.com> <200205131901.g4DJ1U8s069604@apollo.backplane.com> <3CE01595.D045B70D@mindspring.com> <20020513124807.R72322@nexus.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman-Lawrence wrote:
> >Was the result a rejected packet that didn't get transferred, or
> >transferred packets with bad checksums?
> >
> >If the latter, then it's workaroundable in software, which might
> >be worth doing... if only rechecking packets with bad checksums.
> >I fear the former makes more sense, though.  8-(.
> 
>    The chip would calculate the wrong checksum and basically say the packet
> was bad when it was good (and by inference, good when it was bad). I was not
> able to figure out what they got wrong in the algorithm, but if that were
> known, then it is conceivable that the problem could be fixed in software.

Was the "bad packet" DMA'ed in anyway, or just dropped at the card?

The "good packet" problem seems unresolvable, if it ever happened.
8-(.

Has anyone tapped the manufacturer on the shoulder hard enough to
get an answer?

...On to "depression"...

-- 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?3CE01A3A.AAB85F64>