ions, 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.
-DG
David Greenman-Lawrence
Co-founder, The FreeBSD Project - http://www.freebsd.org
>David Greenman-Lawrence 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
>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?
...
>There's no similar comment in the if_bge.c ...
See rev 1.5 and 1.3.2.5 of if_bge.c.
-DG
David Greenm
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.
-DG
David Greenman-Lawrence
Co-founder, The FreeBSD Project - http:
>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 doi
>* David Greenman-Lawrence <[EMAIL PROTECTED]> [020513 13:10] wrote:
>>
>>The card doesn't drop the packet if the IP/TCP checksum is wrong. In my
>> tests, I did a software checksum on the supposedly bad packet, and found it
>> to be good every time.
t;be sure that it was only bad packets being marked good.
It's not. The problem is much more complicated then that. It appears that
some portions are either not added in or are added incorrectly.
-DG
David Greenman-Lawrence
Co-founder, The FreeBSD Project - http://www.freebsd.org
Pr
7 matches
Mail list logo
