From nobody@FreeBSD.org  Thu Dec 20 05:43:13 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 10DED16A418
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Dec 2007 05:43:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 0745713C458
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Dec 2007 05:43:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id lBK5gpYE054109
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Dec 2007 05:42:51 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id lBK5gpL3054108;
	Thu, 20 Dec 2007 05:42:51 GMT
	(envelope-from nobody)
Message-Id: <200712200542.lBK5gpL3054108@www.freebsd.org>
Date: Thu, 20 Dec 2007 05:42:51 GMT
From: Aaron Seelye <aseelye@eltopia.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: bge has checksum problems on the 5703 chipset
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         118879
>Category:       kern
>Synopsis:       [bge] [patch] bge has checksum problems on the 5703 chipset
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 20 05:50:01 UTC 2007
>Closed-Date:    Tue Jul 06 22:16:33 UTC 2010
>Last-Modified:  Tue Jul 06 22:16:33 UTC 2010
>Originator:     Aaron Seelye
>Release:        6.3-PRERELEASE
>Organization:
Eltopia.com
>Environment:
FreeBSD phone1.eltopia.net 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #1: Wed Dec 19 20:53:59 PST 2007     toor@phone1.eltopia.net:/usr/obj/usr/src/sys/PHONE  i386
>Description:
Watching outgoing udp packets (from openser) on port 5060 via tshark,
I was finding that they were just about all saying that there was a
checksum error.  Looking at the source of if_bge.c, I found that the
5700 B0 chipset had a similar problem, so I extended the fix to all the
variants of the 5703, as I didn't know which of the 5703s are broken.
This is replicable on a Dell 2650.  Below is a relevant portion of the
dmesg regarding the interfaces.  You'll find a patch attached to this
PR, but as I'm not anything close to a programmer, I wouldn't doubt if
someone would have a better way of doing this.


Dec 19 21:05:30 phone1 kernel: bge0: <Broadcom BCM5703 A2, ASIC rev. 0x1002> mem 0xfcd10000-0xfcd1ffff irq 28 at device 6.0 on pci3
Dec 19 21:05:30 phone1 kernel: miibus0: <MII bus> on bge0
Dec 19 21:05:30 phone1 kernel: brgphy0: <BCM5703 10/100/1000baseTX PHY> on miibus0
Dec 19 21:05:30 phone1 kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Dec 19 21:05:30 phone1 kernel: bge0: Ethernet address: 00:0d:56:71:54:14
Dec 19 21:05:30 phone1 kernel: bge1: <Broadcom BCM5703 A2, ASIC rev. 0x1002> mem 0xfcd00000-0xfcd0ffff irq 29 at device 8.0 on pci3
Dec 19 21:05:30 phone1 kernel: miibus1: <MII bus> on bge1
Dec 19 21:05:30 phone1 kernel: brgphy1: <BCM5703 10/100/1000baseTX PHY> on miibus1
Dec 19 21:05:30 phone1 kernel: brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Dec 19 21:05:30 phone1 kernel: bge1: Ethernet address: 00:0d:56:71:54:15

>How-To-Repeat:
Detailed in description above.
>Fix:
Patch is attached.

Patch attached with submission follows:

--- if_bge.c.old	2007-05-08 09:18:21.000000000 -0700
+++ if_bge.c	2007-12-19 20:11:10.000000000 -0800
@@ -2433,6 +2433,36 @@
 		ifp->if_hwassist = 0;
 	}
 
+	if (sc->bge_chipid == BGE_CHIPID_BCM5703_A0) {
+		ifp->if_capabilities &= ~IFCAP_HWCSUM;
+		ifp->if_capenable &= IFCAP_HWCSUM;
+		ifp->if_hwassist = 0;
+	}
+
+	if (sc->bge_chipid == BGE_CHIPID_BCM5703_A1) {
+		ifp->if_capabilities &= ~IFCAP_HWCSUM;
+		ifp->if_capenable &= IFCAP_HWCSUM;
+		ifp->if_hwassist = 0;
+	}
+
+	if (sc->bge_chipid == BGE_CHIPID_BCM5703_A2) {
+		ifp->if_capabilities &= ~IFCAP_HWCSUM;
+		ifp->if_capenable &= IFCAP_HWCSUM;
+		ifp->if_hwassist = 0;
+	}
+
+	if (sc->bge_chipid == BGE_CHIPID_BCM5703_A3) {
+		ifp->if_capabilities &= ~IFCAP_HWCSUM;
+		ifp->if_capenable &= IFCAP_HWCSUM;
+		ifp->if_hwassist = 0;
+	}
+
+	if (sc->bge_chipid == BGE_CHIPID_BCM5703_B0) {
+		ifp->if_capabilities &= ~IFCAP_HWCSUM;
+		ifp->if_capenable &= IFCAP_HWCSUM;
+		ifp->if_hwassist = 0;
+	}
+
 	/*
 	 * Figure out what sort of media we have by checking the
 	 * hardware config word in the first 32k of NIC internal memory,


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: remko 
Responsible-Changed-When: Thu Dec 20 07:32:58 UTC 2007 
Responsible-Changed-Why:  
This seems like something for -net 

http://www.freebsd.org/cgi/query-pr.cgi?pr=118879 
State-Changed-From-To: open->analyzed 
State-Changed-By: kris 
State-Changed-When: Tue Dec 25 14:11:09 UTC 2007 
State-Changed-Why:  
This is most likely not a bug unless you can confirm the bad checksums 
from *ANOTHER* machine on the same link.  When hardware checksum 
offload is in use, the OS does not compute the checksum (it happens in 
the NIC as the packet is transmitted) so tcpdump sees a "wrong" 
checksum.  See the tcpdump manpage. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=118879 
State-Changed-From-To: analyzed->closed 
State-Changed-By: yongari 
State-Changed-When: Tue Jul 6 22:15:29 UTC 2010 
State-Changed-Why:  
As Kris pointed out, it's not a bug of bge(4). It's normal to see bad 
checksummed frames for out-going traffic on sender side as bpf 
listner sees frames before controller performs checksum 
calculation. 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Tue Jul 6 22:15:29 UTC 2010 
Responsible-Changed-Why:  
Track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=118879 
>Unformatted:
