Date: Wed, 20 Feb 2002 06:42:34 -0800 From: "Tomic, Gary" <gary.tomic@cacheflow.com> To: "'freebsd-bugs@FreeBSD.ORG'" <freebsd-bugs@FreeBSD.ORG> Subject: Tigon 2 network card bug fixed, but unsure how to proceed Message-ID: <EB19A8A38B497D4FA6C88EADE3A8607F021E0873@cf-bay-exch-04.cacheflow.com>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1BA1C.D54BF4A0
Content-Type: text/plain;
charset="iso-8859-1"
I have discovered a bug in the firmware used on the tigon 2 gigabit ethernet
card, and have worked with 3com to resolve the problem. They have provided
me with a new firmware image version 12.4.18 that fixes the problem. I've
included the steps to reproduce the problem, however since we are using a
different OS than freeBSD, I do not have a setup to apply and test this fix
on freeBSD. I am loathe to check-in a fix before testing it, so I'm
wondering if anyone would be willing to do this for me. I have found a
possible bug report in the system that may be fixed by the new firmware.
Specifically
Change on 2000/07/13 by wpaul@cvs2p4 <mailto:wpaul@cvs2p4>
Temporarily disable support for hardware checksum offload in the
Tigon
driver. According to dg, ftp.freesoftware.com
<ftp://ftp.freesoftware.com>; will begin transmitting
packets with bogus checksums after about 12 hours under load and
won't
stop until the interface is reset. I'm not at all sure how to track
this
bug down right now since it's most likely in the firmware, and we
want
this to at least be stable for the 4.1 release.
Specifically the problem occurs if HW checksum offload is enabled, and the
following occurs (high level description):
* Packet fragmentation has occured elsewhere in the network .
* Packet arrives on interface and is not destined for the freeBSD
machine. freeBSD must be configured to forward such packets.
* Forwarded with only the IP header modified. The TCP/UDP checksum is
not re-calculated because it has not changed
* There was an assumption on the network card that even if not
calculating TCP/UDP checksum, that fragments must be presented to the
network card in order, and must be terminated with a last fragment command
* If this requirement is not met, the 3com firmware goes into a state
where it will never calculate the TCP/UDP checksum from that point forward.
The only fix was to reset the card.
* This fragment order reliance is only necessary when the card needs
to calculate the TCP/UDP checksum, so 3com has removed this requirement if
TCP/UDP checksums are not calculated. Since packets that are forwarded do
not need their TCP/UDP checksum recalculated, the problem is then fixed.
If anyone would like more detailed info, I'd be happy to provide it.
Gary
Senior System Software Engineer
CacheFlow
------_=_NextPart_001_01C1BA1C.D54BF4A0
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=539552514-20022002><FONT face=Arial size=2>I have discovered a
bug in the firmware used on the tigon 2 gigabit ethernet card, and have worked
with 3com to resolve the problem. They have provided me with a new firmware
image version 12.4.18 that fixes the problem. I've included the steps to
reproduce the problem, however since we are using a different OS than freeBSD, I
do not have a setup to apply and test this fix on freeBSD. I am loathe to
check-in a fix before testing it, so I'm wondering if anyone would be willing to
do this for me. I have found a possible bug report in the system that may be
fixed by the new firmware. Specifically</FONT></SPAN></DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial size=2><FONT
color=#0000ff>Change on 2000/07/13 by </FONT><A
href="mailto:wpaul@cvs2p4">wpaul@cvs2p4</A></FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial size=2><FONT
color=#0000ff> Temporarily disable
support for hardware checksum offload in the
Tigon<BR> driver. According to dg,
</FONT><A href="ftp://ftp.freesoftware.com">ftp.freesoftware.com</A><FONT
color=#0000ff> will begin
transmitting<BR> packets with bogus
checksums after about 12 hours under load and
won't<BR> stop until the interface is
reset. I'm not at all sure how to track
this<BR> bug down right now since it's
most likely in the firmware, and we
want<BR> this to at least be stable
for the 4.1 release.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial size=2>Specifically the
problem occurs if HW checksum offload is enabled, and the following occurs (high
level description):</FONT></SPAN></DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial
size=2></FONT></SPAN> </DIV><SPAN class=539552514-20022002>
<UL>
<LI><SPAN class=582343519-08022002><SPAN class=651092400-17022002><FONT
face=Arial><FONT size=2><SPAN class=539552514-20022002>Packet fragmentation
has occured elsewhere in the
network</SPAN></FONT></FONT></SPAN></SPAN> <SPAN
class=539552514-20022002><FONT face=Arial size=2>.</FONT></SPAN>
<LI><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN class=539552514-20022002>Packet arrives on
interface and is not destined for the freeBSD machine. freeBSD must be
configured to forward such packets.</SPAN></SPAN></FONT></SPAN>
<LI><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002>Forwarded with only the IP header modified. The
TCP/UDP checksum is not re-calculated because it has not
changed</SPAN></FONT></SPAN>
<LI><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002>There was an assumption on the network card that even
if not calculating TCP/UDP checksum, that fragments must be presented to the
network card in order, and must be terminated with a last fragment
command</SPAN></FONT></SPAN>
<LI><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002>If this requirement is not met, the 3com firmware
goes into a state where it will never calculate the TCP/UDP checksum from that
point forward. The only fix was to reset the card.</SPAN></FONT></SPAN>
<LI><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002>This fragment order reliance is only necessary when
the card needs to calculate the TCP/UDP checksum, so 3com has removed this
requirement if TCP/UDP checksums are not calculated. Since packets that are
forwarded do not need their TCP/UDP checksum recalculated, the problem is then
fixed. </SPAN></FONT></SPAN></LI></UL>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN class=539552514-20022002>If anyone would like
more detailed info, I'd be happy to provide
it.</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN
class=539552514-20022002></SPAN></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN
class=539552514-20022002>Gary</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN class=539552514-20022002>Senior System Software
Engineer</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN
class=539552514-20022002>CacheFlow</SPAN></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN
class=539552514-20022002></SPAN></SPAN></FONT></SPAN> </DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN
class=651092400-17022002><SPAN
class=539552514-20022002></SPAN></SPAN></FONT></SPAN> </DIV></SPAN></BODY></HTML>
------_=_NextPart_001_01C1BA1C.D54BF4A0--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EB19A8A38B497D4FA6C88EADE3A8607F021E0873>