From owner-freebsd-bugs  Wed Feb 20  6:43: 5 2002
Delivered-To: freebsd-bugs@freebsd.org
Received: from mailrelay.cacheflow.com (mailrelay.cacheflow.com [216.52.23.19])
	by hub.freebsd.org (Postfix) with ESMTP id 18A6D37B416
	for <freebsd-bugs@FreeBSD.ORG>; Wed, 20 Feb 2002 06:42:40 -0800 (PST)
Received: from cf-bay-exch-03.cacheflow.com (cf-bay-exch-03.cacheflow.com [216.52.23.24])
	by mailrelay.cacheflow.com (8.12.2/8.12.2) with ESMTP id g1KEgdhK009860
	for <freebsd-bugs@FreeBSD.ORG>; Wed, 20 Feb 2002 06:42:39 -0800
Received: by cf-bay-exch-03.cacheflow.com with Internet Mail Service (5.5.2653.19)
	id <FA4X6L5S>; Wed, 20 Feb 2002 06:42:42 -0800
Message-ID: <EB19A8A38B497D4FA6C88EADE3A8607F021E0873@cf-bay-exch-04.cacheflow.com>
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
Date: Wed, 20 Feb 2002 06:42:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BA1C.D54BF4A0"
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-bugs.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-bugs>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-bugs>
X-Loop: FreeBSD.org

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>&nbsp;</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>&nbsp;</DIV>
<DIV><SPAN class=539552514-20022002><FONT face=Arial size=2><FONT 
color=#0000ff>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Temporarily disable 
support for hardware checksum offload in the 
Tigon<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; driver. According to dg, 
</FONT><A href="ftp://ftp.freesoftware.com">ftp.freesoftware.com</A><FONT 
color=#0000ff> will begin 
transmitting<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets with bogus 
checksums after about 12 hours under load and 
won't<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stop until the interface is 
reset. I'm not at all sure how to track 
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bug down right now since it's 
most likely in the firmware, and we 
want<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;<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>&nbsp;</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>&nbsp;</DIV>
<DIV><SPAN class=582343519-08022002><FONT face=Arial size=2><SPAN 
class=651092400-17022002><SPAN 
class=539552514-20022002></SPAN></SPAN></FONT></SPAN>&nbsp;</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