NetBSD Problem Report #40018
From tron@zhadum.org.uk Mon Nov 24 20:29:56 2008
Return-Path: <tron@zhadum.org.uk>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id EE4C563B8BD
for <gnats-bugs@gnats.NetBSD.org>; Mon, 24 Nov 2008 20:29:55 +0000 (UTC)
Message-Id: <200811242029.mAOKTkqW006103@colwyn.zhadum.org.uk>
Date: Mon, 24 Nov 2008 20:29:46 GMT
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@gnats.NetBSD.org
Subject: Using hw TCP/IPv4 checksums on bge(4) causes connection failures
X-Send-Pr-Version: 3.95
>Number: 40018
>Category: kern
>Synopsis: Using hw TCP/IPv4 checksums on bge(4) causes connection failures
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Nov 24 20:30:00 +0000 2008
>Closed-Date: Mon May 02 19:08:08 +0000 2011
>Last-Modified: Wed Jun 13 16:00:04 +0000 2012
>Originator: Matthias Scheler
>Release: NetBSD 5.0_BETA 2008-11-22 sources
>Organization:
Matthias Scheler http://zhadum.org.uk/
>Environment:
System: NetBSD colwyn.zhadum.org.uk 5.0_BETA NetBSD 5.0_BETA (COLWYN.64) #0: Sat Nov 22 13:29:35 GMT 2008 tron@lyssa.zhadum.org.uk:/src/sys/compile/COLWYN.64 amd64
Architecture: x86_64
Machine: amd64
>Description:
Since yesterday I'm using a HP Proliant ML110 G4 as my mail server using the
on-board bge(4) network interface:
bge0 at pci3 dev 0 function 0: Broadcom BCM5721 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 17
bge0: ASIC unknown BCM575x family (0x4201), Ethernet address 00:1c:c4:xx:xx:xx
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM5750 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
The machine was setup to use all the hardware offload features provided
by the interface:
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
enabled=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
address: 00:1c:c4:xx:xx:xx
media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause)
status: active
One of my users started experiencing problems sending e-mails using
Outlook Express on a Windows XP Pro system behind an A-DSL router.
The A-DSL router uses PPPoE and is therefore restricted to a MTU of
1492 bytes.
Here is a "tcpdump" output for a broken SMTP session:
19:18:18.886636 IP (tos 0x0, ttl 114, id 1959, offset 0, flags [DF], proto TCP (6), length 48) 192.0.2.1.15415 > 81.187.181.119.587: S, cksum 0xf20b (correct), 4076085614:4076085614(0) win 16384 <mss 1452,nop,nop,sackOK>
19:18:18.886672 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 48, bad cksum 0 (->3c92)!) 81.187.181.119.587 > 192.0.2.1.15415: S, cksum 0xe852 (correct), 217365675:217365675(0) ack 4076085615 win 32768 <mss 1460,sackOK,nop,nop>
19:18:19.116434 IP (tos 0x0, ttl 241, id 65259, offset 0, flags [none], proto TCP (6), length 40) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x8d17 (correct), 1:1(0) ack 1 win 2048
19:18:19.117507 IP (tos 0x0, ttl 64, id 52571, offset 0, flags [DF], proto TCP (6), length 93, bad cksum 0 (->6f09)!) 81.187.181.119.587 > 192.0.2.1.15415: P, cksum 0xfe85 (incorrect (-> 0x858e), 1:54(53) ack 1 win 33580
19:18:19.121950 IP (tos 0x0, ttl 114, id 1960, offset 0, flags [DF], proto TCP (6), length 40) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x5107 (correct), 1:1(0) ack 1 win 17424
19:18:19.353061 IP (tos 0x0, ttl 114, id 1961, offset 0, flags [DF], proto TCP (6), length 61) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0xa573 (correct), 1:22(21) ack 54 win 17371
19:18:19.353125 IP (tos 0x0, ttl 64, id 52583, offset 0, flags [DF], proto TCP (6), length 215, bad cksum 0 (->6e83)!) 81.187.181.119.587 > 192.0.2.1.15415: P, cksum 0xfeff (incorrect (-> 0x39ff), 54:229(175) ack 22 win 33580
19:18:19.600246 IP (tos 0x0, ttl 114, id 1964, offset 0, flags [DF], proto TCP (6), length 69) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0xe26f (correct), 22:51(29) ack 229 win 17196
19:18:19.600305 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 55, bad cksum 0 (->3c8b)!) 81.187.181.119.587 > 192.0.2.1.15415: P, cksum 0xfe5f (incorrect (-> 0xf1af), 229:244(15) ack 51 win 33580
19:18:19.832051 IP (tos 0x0, ttl 114, id 1965, offset 0, flags [DF], proto TCP (6), length 77) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0xf4e8 (correct), 51:88(37) ack 244 win 17181
19:18:19.832105 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 58, bad cksum 0 (->3c88)!) 81.187.181.119.587 > 192.0.2.1.15415: P, cksum 0xfe62 (incorrect (-> 0x31f5), 244:262(18) ack 88 win 33580
19:18:20.065012 IP (tos 0x0, ttl 114, id 1968, offset 0, flags [DF], proto TCP (6), length 46) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0xab15 (correct), 88:94(6) ack 262 win 17163
19:18:20.065199 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 66, bad cksum 0 (->3c80)!) 81.187.181.119.587 > 192.0.2.1.15415: P, cksum 0xfe6a (incorrect (-> 0xa8f5), 262:288(26) ack 94 win 65535
19:18:20.326382 IP (tos 0x0, ttl 114, id 1969, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:18:20.326387 IP (tos 0x0, ttl 114, id 1970, offset 0, flags [DF], proto TCP (6), length 151) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0x86a6 (correct), 1546:1657(111) ack 288 win 17137
19:18:20.326405 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3c8e)!) 81.187.181.119.587 > 192.0.2.1.15415: ., cksum 0xfe5c (incorrect (-> 0x283b), 288:288(0) ack 94 win 65535 <nop,nop,sack 1 {1546:1657}>
19:18:20.562681 IP (tos 0x0, ttl 114, id 1973, offset 0, flags [DF], proto TCP (6), length 45) 192.0.2.1.15415 > 81.187.181.119.587: P, cksum 0x056b (correct), 1657:1662(5) ack 288 win 17137
19:18:20.562704 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3c8e)!) 81.187.181.119.587 > 192.0.2.1.15415: ., cksum 0xfe5c (incorrect (-> 0x2836), 288:288(0) ack 94 win 65535 <nop,nop,sack 1 {1546:1662}>
19:18:20.821478 IP (tos 0x0, ttl 114, id 1974, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:18:22.822304 IP (tos 0x0, ttl 114, id 1981, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:18:26.837216 IP (tos 0x0, ttl 114, id 1985, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:18:34.859651 IP (tos 0x0, ttl 114, id 1991, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:18:50.810659 IP (tos 0x0, ttl 114, id 1994, offset 0, flags [DF], proto TCP (6), length 1492) 192.0.2.1.15415 > 81.187.181.119.587: ., cksum 0x3045 (correct), 94:1546(1452) ack 288 win 17137
19:19:20.279884 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3c8e)!) 81.187.181.119.587 > 192.0.2.1.15415: R, cksum 0xfe5c (incorrect (-> 0x2832), 288:288(0) ack 94 win 65535 <nop,nop,sack 1 {1546:1662}>
[I can provide a ".pcap" file on request.]
The SMTP daemon terminated the TCP connection after 60 seconds because
it thought that the connection had gone idle.
As I was surprised by the TCP problem I tried to change the interface
settings. I could finally fix the problem by disabling hardware-assisted
TCP/IPv4 checksums with "ifconfig bge0 -tcp4csum" while hardware-assisted
IPv4 (and UDP) checksums were still enabled.
This looks like a problem with TCP checksum offload in the bge(4) driver
or a hardware bug, not sure which one it is. But if it is a hardware
problem then bge(4) shouldn't offer that feature on this chip.
>How-To-Repeat:
>Fix:
Not known.
>Release-Note:
>Audit-Trail:
From: buhrow@lothlorien.nfbcal.org (Brian Buhrow)
To: gnats-bugs@gnats.netbsd.org
Cc: buhrow@lothlorien.nfbcal.org
Subject: Re: kern/40018: Using hw TCP/IPv4 checksums on bge(4) causes connection failures
Date: Wed, 15 Sep 2010 23:27:07 -0700
[If we could get this patch pulled up to 5.x sources, that would be
wonderful!]
hello. Could you try the following patch and let me know if you get
better results? I'm testing it on a couple of machines here, and, so far,
things look promising.
Our driver initializes the Broadcom hardware to peform a tcp and udp
checksum on only the payload of the tcp or udp packet, rather than the
entire packet. The FreeBSD and Linux drivers instruct the hardware to compute
the checksum for the entire packet. I believe the bug is that some revisions
of the BCM hardware, under certain circumstances, revert to doing the
complete checksum calculation, as the FreeBSD and Linux drivers request, while
things are running. As
a result, when we pull the computed checksum from the hardware and pass it
up to the upper layers, we assume the checksum is the more minimal
one, and the upper layers perform the appropriate checks, which, when this
happens, cause the packet to be rejected because the resultant checksum is
decidedly incorrect.
This patch changes the driver to instruct the hardware to perform the
checksum over the entire packet, just as the FreeBSD and Linux drivers do,
and to notify the upper layers appropriately.
If this patch works, I'll amend the bug report to include the patch
and this explanation.
The first patch file below was made against 5.x sources, but applies cleanly
to 4.x, 3.x and 2.x sources as well.
The second patch file is against -current sources as of September 15, 2010.
Here is a followup explanation as to what and why the patch does what
it does.
Hello. Yes, this asymetry is intentional. Both the Linux and FreeBSD
drivers behave this way. My understanding is that the stack presents a
well formed packet to the driver for transmition to the Net, including a
calculated checksum. My analysis of what I was seeing did not indicate
that we were generating packets with bad checksums, only that we were
discarding a very high percentage of incoming packets for failing the
checksum tests. And, in fact, the known bug is that the BCM hardware
doesn't do the pseudo calculations on outbound packets. There's anotefrom
2003 in our driver's history log which says that an assumption was made
that if the chip couldn't do the proper calculations on outbound
packets, then we shouldn't trust it to do the proper calculation on inbound
packets. A fine assumption, except that over the course of time, no one
else has used this mode of operation, and, apparently, not tested it
either.
So far, the machines running this patch look good. I'm seeing a few
checksum failures, but given that these are name and mail servers which see
traffic from all over the Net, I'm not surprised to see some checksum
issues. Before the patch, checksum counters were incrementing between 1
and 10 times a second. Now, checksum errors are down in the noise and
matching my machines with different drivers and/or their hardware flags
turned off.
-Brian
Here is the note I referenced above. The last paragraph is relevant
to this discussion. The chips apparently do do the pseudo header
calculation on packet reception, even if instructed not to. I can't tell
if the Linux driver ever had to resort to not getting pseudo data on packet
reception, but neither the Linux or FreeBSD drivers indicate that this was
a problem on any chip revisions.
revision 1.46
date: 2003/08/22 03:32:35; author: jonathan; state: Exp; lines: +93 -14
Check in hooks to fix checksum offload on bge devices. Empirical
observation is that some 570x devices can get themselves into a state
where they miscompute off-loaded TCP or UDP checksums on packets so
small that Ethernet padding is required. Further obsevation suggests
that the bge checksum-offload hardware is adding those padding bytes
into its TCP checksum computation. (Once a 5700 gets in this state,
even a warm boot won't fix it: it needs a hard powerdown.)
Work around the problem by padding such runts with zeros: even if the
checksum-offload adds in extra zeros, the resulting sum will be correct.
Also, dont trust the checksum-offload on received packets smaller than
the minimum ethernet frame, in case the Rx-side has a similar bug.
Finally, on packets where we do trust the outboard Rx-side TCP or UDP
checksum, the bge did not include the pseudo-header. Set the
M_CSUM_NO_PSEUDOHDR bit as well as M_CSUM_DATA, and rely on
udp_input() or tcp_input() adding in the sum via in_cksum_phdr().
----------------------------
On Sep 15, 8:55am, Chris Ross wrote:
} Subject: Re: Hardware checksums on bge(4) interfaces
}
} The patch, left below, looks like it removes the =
} BGE_MODECTL_RX_NO_PHDR_CSUM bit, but leaves the =
} BGE_MODECTL_TX_NO_PHDR_CSUM bit in place. By reading your description, =
} this may solve only half of the problem.
}
} I don't know, of course, but it looked worth asking about... Did you =
} mean to leave the TX side without calculating the checksum of the =
} pseudo-header?
}
} - Chris
}
}
>-- End of excerpt from Chris Ross
[...]
As of this writing, I've been runing this patch on a number of
production machines for 24 hours and haven't seen any problems with all
hardware flags enabled. I don't have any machines in production that can
do tso4 operations in hardware, so haven't tested that aspect of things. I
believe, however, that they'll work fine since, again, this patch makes us
drive the chips the same way the Linux and FreeBSD drivers do.
Here is a list of chips I've been runing without issue.
-Brian
bge0 at pci1 dev 2 function 0: Broadcom BCM5704C Dual Gigabit Ethernet
bge0: interrupting at ioapic1 pin 1
bge0: ASIC BCM5704 A3 (0x2003), Ethernet address xx:xx:xx:xx:xx
brgphy0 at bge0 phy 1: BCM5704 1000BASE-T media interface, rev. 0
bge1 at pci1 dev 2 function 1: Broadcom BCM5704C Dual Gigabit Ethernet
bge1: interrupting at ioapic1 pin 2
bge1: ASIC BCM5704 A3 (0x2003), Ethernet address xx:xx:xx:xx:xx
brgphy1 at bge1 phy 1: BCM5704 1000BASE-T media interface, rev. 0
bge0 at pci1 dev 2 function 0: Broadcom BCM5703X Gigabit Ethernet
bge0: interrupting at ioapic1 pin 1
bge0: ASIC BCM5703 A2 (0x1002), Ethernet address xx:xx:xx:xx:xx
brgphy0 at bge0 phy 1: BCM5703 1000BASE-T media interface, rev. 2
bge1 at pci1 dev 3 function 0: Broadcom BCM5703X Gigabit Ethernet
bge1: interrupting at ioapic1 pin 2
bge1: ASIC BCM5703 A2 (0x1002), Ethernet address xx:xx:xx:xx:xx
brgphy1 at bge1 phy 1: BCM5703 1000BASE-T media interface, rev. 2
bge0 at pci6 dev 4 function 0: Broadcom BCM5714/5715 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 16
bge0: ASIC unknown BCM5714 (0x9003), Ethernet address xx:xx:xx:xx:xx
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM5714 1000BASE-T media interface, rev. 0
[And finally... The patches]
[Patch against 5.x sources which applies also to 4.x, 3.x and 2.x sources.]
Index: if_bge.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.152.4.2
diff -u -r1.152.4.2 if_bge.c
--- if_bge.c 2 Feb 2009 20:44:16 -0000 1.152.4.2
+++ if_bge.c 15 Sep 2010 07:12:43 -0000
@@ -1444,7 +1444,7 @@
*/
CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_DMA_SWAP_OPTIONS|
BGE_MODECTL_MAC_ATTN_INTR|BGE_MODECTL_HOST_SEND_BDS|
- BGE_MODECTL_TX_NO_PHDR_CSUM|BGE_MODECTL_RX_NO_PHDR_CSUM);
+ BGE_MODECTL_TX_NO_PHDR_CSUM);
/* Get cache line size. */
cachesize = pci_conf_read(sc->sc_pc, sc->sc_pcitag, BGE_PCI_CACHESZ);
@@ -3276,7 +3276,7 @@
cur_rx->bge_tcp_udp_csum;
m->m_pkthdr.csum_flags |=
(M_CSUM_TCPv4|M_CSUM_UDPv4|
- M_CSUM_DATA|M_CSUM_NO_PSEUDOHDR);
+ M_CSUM_DATA);
}
/*
[Patch against if_bge.c -current as of September 15, 2010.]
--- if_bge.c.orig 2010-09-15 00:50:06.000000000 -0700
+++ if_bge.c 2010-09-15 00:53:07.000000000 -0700
@@ -1866,7 +1866,7 @@
*/
CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_DMA_SWAP_OPTIONS |
BGE_MODECTL_MAC_ATTN_INTR | BGE_MODECTL_HOST_SEND_BDS |
- BGE_MODECTL_TX_NO_PHDR_CSUM | BGE_MODECTL_RX_NO_PHDR_CSUM);
+ BGE_MODECTL_TX_NO_PHDR_CSUM);
/*
* BCM5701 B5 have a bug causing data corruption when using
@@ -3444,7 +3444,7 @@
cur_rx->bge_tcp_udp_csum;
m->m_pkthdr.csum_flags |=
(M_CSUM_TCPv4|M_CSUM_UDPv4|
- M_CSUM_DATA|M_CSUM_NO_PSEUDOHDR);
+ M_CSUM_DATA);
}
/*
From: buhrow@lothlorien.nfbcal.org (Brian Buhrow)
To: gnats-bugs@gnats.netbsd.org
Cc: buhrow@lothlorien.nfbcal.org
Subject: Re: kern/40018: Using hw TCP/IPv4 checksums on bge(4) causes connection failures
Date: Mon, 22 Nov 2010 17:30:15 -0800
Hello. Following up on this patch, I've now tested it on a host chip
with TSO. Again, no issues. The part is:
bge0 at pci4 dev 0 function 0: Broadcom BCM5721 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 16
bge0: ASIC BCM5751 A1 (0x4101), Ethernet address 00:30:48:78:5e:28
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM5750 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FD
X, auto
ppb4 at pci0 dev 5 function 0: Intel product 0x3598 (rev. 0x0c)
From: River Tarnell <r.tarnell@IEEE.ORG>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: kern/40018: Using hw TCP/IPv4 checksums on bge(4) causes
connection failures
Date: Fri, 28 Jan 2011 17:04:43 +0000
I recently ran into this problem using 5.1.0_PATCH:
bge0 at pci3 dev 0 function 0: Broadcom BCM5721 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 16
bge0: ASIC BCM5750 C1 (0x4201), Ethernet address 00:1e:c9:ff:19:24
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM5750 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
After applying the patch, the problem appears to be fixed for me.
- river.
From: Brian Buhrow <buhrow@NetBSD>
* To: source-changes%NetBSD.org@localhost
* Subject: CVS commit: src/sys/dev/pci
* From: "Brian Buhrow" <buhrow%netbsd.org@localhost>
* Date: Mon, 18 Apr 2011 22:05:39 +0000
__________________________________________________________________
Module Name: src
Committed By: buhrow
Date: Mon Apr 18 22:05:39 UTC 2011
Modified Files:
src/sys/dev/pci: if_bge.c
Log Message:
Fixes for kern/40018.
Our driver initializes the Broadcom hardware to peform a tcp and udp
checksum on only the payload of the tcp or udp packet, rather than the
entire packet. The FreeBSD, OpenBSD and Linux drivers instruct the hardware
to compute
the checksum for the entire packet. I believe the bug is that some revisions
of the BCM hardware, under certain circumstances, revert to doing the
complete checksum calculation, as the FreeBSD, OpenBSD and Linux drivers
request, while things are running. As
a result, when we pull the computed checksum from the hardware and pass it
up to the upper layers, we assume the checksum is the more minimal
one, and the upper layers perform the appropriate checks, which, when this
happens, cause the packet to be rejected because the resultant checksum is
decidedly incorrect.
This patch changes the driver to instruct the hardware to perform the
checksum over the entire packet, just as the FreeBSD, OpenBSD and
Linux drivers do, and to notify the upper layers appropriately.
This patch appears to work on all revisions of the hardware that have been
tested. (See the list in the bug report.)
this patch is approved by tls.
To generate a diff of this commit:
cvs rdiff -u -r1.193 -r1.194 src/sys/dev/pci/if_bge.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
__________________________________________________________________
Hello. Here's the 5.x commit message from the engineering team.
-thanks
-Brian
Pulled up to netbsd-5:
sys/dev/pci/if_bge.c 1.194
Perform hardware checksum over the entire packet, as other OS
drivers do. PR#40018.
[buhrow, ticket #1601]
__________________________________________________________________
State-Changed-From-To: open->pending-pullups
State-Changed-By: buhrow@NetBSD.org
State-Changed-When: Mon, 18 Apr 2011 22:27:49 +0000
State-Changed-Why:
Patch committed, pullup requested.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: buhrow@NetBSD.org
State-Changed-When: Mon, 02 May 2011 19:08:08 +0000
State-Changed-Why:
The pullup request has been fulfilled and the patches have been committed to NetBSD-5.
From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40018 (Using hw TCP/IPv4 checksums on bge(4) causes
connection failures)
Date: Tue, 7 Jun 2011 13:05:19 +0100
On Mon, May 02, 2011 at 07:08:09PM +0000, buhrow@NetBSD.org wrote:
> Synopsis: Using hw TCP/IPv4 checksums on bge(4) causes connection failures
>
> State-Changed-From-To: pending-pullups->closed
> State-Changed-By: buhrow@NetBSD.org
> State-Changed-When: Mon, 02 May 2011 19:08:08 +0000
> State-Changed-Why:
> The pullup request has been fulfilled and the patches have been committed to NetBSD-5.
I've now re-configured the machine on which I encountered this bug to
use the on-board bge(4) instead of a wm(4) PCI-e card. It works fine
so far but it is of course much too early to tell whether the problem
will occur again.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
From: "Stephen Borrill" <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40018 CVS commit: [netbsd-4] src/sys/dev/pci
Date: Wed, 13 Jun 2012 15:55:04 +0000
Module Name: src
Committed By: sborrill
Date: Wed Jun 13 15:55:03 UTC 2012
Modified Files:
src/sys/dev/pci [netbsd-4]: if_bge.c
Log Message:
Pull up the following revisions(s) (requested by buhrow in ticket #1449):
sys/dev/pci/if_bge.c: 1.194 via patch
Instruct hardware to perform checksumming over the entire packet not just
over the payload and notify upper layers appropriately. Fixes PR kern/40018.
To generate a diff of this commit:
cvs rdiff -u -r1.122.2.11 -r1.122.2.12 src/sys/dev/pci/if_bge.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home