[EMAIL PROTECTED] wrote:
>
> I guess I incorrectly assumed that the card only had a problem with
> falsely marking packets as bad, and not marking bad ones as good.
That is the impression I was left with using hardware with some different Broadcom
parts, (about a year ago). Possibly also conne
On Mon, May 13, 2002 at 09:19:18PM -0700, Peter Wemm wrote:
> Terry Lambert wrote:
>
> > Has anyone tapped the manufacturer on the shoulder hard enough to
> > get an answer?
>
> "Why are you not using Linux or another supported OS?"
It's not like they support development of the Linux tg3 driver
Peter Wemm wrote:
> Terry Lambert wrote:
> > Has anyone tapped the manufacturer on the shoulder hard enough to
> > get an answer?
>
> "Why are you not using Linux or another supported OS?"
>
> No, they so far have steadfastly refused to supply information about bugs
> and errata in such a way th
Terry Lambert wrote:
> Has anyone tapped the manufacturer on the shoulder hard enough to
> get an answer?
"Why are you not using Linux or another supported OS?"
No, they so far have steadfastly refused to supply information about bugs
and errata in such a way that we could use them in an open s
* David Greenman-Lawrence <[EMAIL PROTECTED]> [020513 15:40] wrote:
> >* 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 f
>Actually, if you could find one of these, it would probably give
>enough information that we could figure out what kind of error it
>was giving. If it's just the incremental checksum 0x (-0)
>problem from one's complement vs. two's complement, then you could
>be sure that it was only bad pac
Alfred Perlstein wrote:
> * 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. So it DMA's correc
>* 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. So it DMA's correctly, the checksum is jus
* 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. So it DMA's correctly, the checksum is just cal
>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
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 fo
>> :Can you guys elaborate on the problem? Was it on incoming checksums,
>> :outgoing checksums, or both?
>>
>> It was on incoming checksums I believe.
>
>Was the result a rejected packet that didn't get transferred, or
>transferred packets with bad checksums?
>
>If the latter, then it's wor
David Greenman-Lawrence wrote:
> >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.
:> This change was made on 14-December-01 by DG. Anyone with an earlier
:> driver may be running with checksums enabled.
:
:OK... Ugh. Any way to get the word "checksum" into that comment?
:I plead search-blindness.
:
:
:> :Can you guys elaborate on the problem? Was it on incoming chec
Matthew Dillon wrote:
> Yup. Of course I am completely Jaded now after listening to B.P.
> curse the chipset while he was debugging it :-)
I like B.P. 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
>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 Greenman-Lawrence
Co-founder, The
: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-(.
Yup. Of course I
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
On Mon, 13 May 2002, David Greenman-Lawrence wrote:
> >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. Th
>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
>> resulted in the commit to disable the receive
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
> resulted in the commit to disable the receive hardw
:>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 p
>Jamie Heckford wrote:
>> I read in the mailling lists mentions of hardware checksum problems
>> with the chipset.. did anyone know what the final outcome with
>> this problem was and if any changes had been MFC'd?
>
>The problems were only when coupled with VLAN tagging.
>
>I'm not sure if the 57
Jamie Heckford wrote:
> I read in the mailling lists mentions of hardware checksum problems
> with the chipset.. did anyone know what the final outcome with
> this problem was and if any changes had been MFC'd?
The problems were only when coupled with VLAN tagging.
I'm not sure if the 5701 was s
24 matches
Mail list logo
