NetBSD Problem Report #40605
From ejelly@green-jelly.ejelly.net Wed Feb 11 00:57:15 2009
Return-Path: <ejelly@green-jelly.ejelly.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id DD62863BAB8
for <gnats-bugs@gnats.NetBSD.org>; Wed, 11 Feb 2009 00:57:14 +0000 (UTC)
Message-Id: <20090211005711.AFA0970DCE@green-jelly.explicit.ejelly.net>
Date: Wed, 11 Feb 2009 01:57:11 +0100 (CET)
From: Julien Oster <netbsd-pr@pool.julien-oster.de>
Reply-To: Julien Oster <netbsd-pr@pool.julien-oster.de>
To: gnats-bugs@gnats.NetBSD.org
Subject: forwarded IPv6 TCP packets get mangled by gif0 interface
X-Send-Pr-Version: 3.95
>Number: 40605
>Category: kern
>Synopsis: forwarded IPv6 TCP packets get mangled by gif0 interface
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: tsutsui
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Feb 11 01:00:01 +0000 2009
>Closed-Date: Sat Oct 24 15:15:51 +0000 2009
>Last-Modified: Sat Nov 14 20:15:02 +0000 2009
>Originator: Julien Oster
>Release: NetBSD 5.0_RC1
>Organization:
>Environment:
System: NetBSD xxx 5.0_RC1 NetBSD 5.0_RC1 (XXX) #0: Wed Feb 4 00:04:44 CET 2009 root@xxx:/usr/src/sys/arch/amd64/compile/XXX amd64
Architecture: x86_64
Machine: amd64
>Description:
01:45 < julien> I think I found a bug in NetBSD 5.0RC1 gif interface (ipv6-over-ipv4 tunnel) code
01:45 < yyyy> julien: File a PR
01:45 < julien> yes, I will, no time right now however
01:46 < julien> 0x0000: 6000 0000 0028 ...
01:46 < julien> this is the start of an IPv6 header. when it contains ICMP (when I try to ping), it stays fine after being
encapsulated.
01:46 < julien> if it contains TCP, it suddenly looks like this:
01:47 < julien> 0x0000: c699 0000 0028 ...
01:47 < julien> which is just plain wrong, and those packets get dropped
01:47 < yyyy> julien: What should it look like?
01:47 < yyyy> Or should it be the same?
01:47 < julien> yyyy, 6000 0000 0028
01:48 < julien> somehow, the first two bytes are changed.
01:48 < julien> only for packets which got forwarded bei the machine holding the gif tunnel, though!
01:48 < julien> TCP packets originating from that machine aren't mangled
01:48 < julien> the tcpdump on the gif0 interface itself is fine. on the output interface, not anymore.
01:48 < julien> you know what, I'll just paste this conversation %)
01:49 < yyyy> lol
pf compiled into kernel. Disabling pf completely with pfctl -d doesn't help, though.
So far, I could only observe this with TCP packets (which means IPv6 TCP doesn't work
at all here), but not with ICMP.
>How-To-Repeat:
Set up a NetBSD server with a gif0 IPv4-IPv6 tunnel interface, let it forward IPv6
packets, try to establish an IPv6 TCP connection from a machine behind it. Observe
valid packets on gif0, invalid encapsulated packets on the output interface (IP version
is even 9 instead of 6!)
>Fix:
>Release-Note:
>Audit-Trail:
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40605
Date: Sat, 4 Apr 2009 19:01:50 +0200
Hi,
I just wanted to add that I can reproduce this, too. Packets sent from the
host itself arrive fine, but forwarded packets have a wrong version header (9
instead of 6).
Can someone please have a look into this? I really need IPv6 for my daily work
and this is kind of a show-stopper right now.
Best regards,
Michael
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
Julien Oster <netbsd-pr@pool.julien-oster.de>
Cc:
Subject: Re: kern/40605
Date: Sat, 4 Apr 2009 13:51:01 -0400
On Apr 4, 5:05pm, michael+netbsd@stapelberg.de (Michael Stapelberg) wrote:
-- Subject: Re: kern/40605
| The following reply was made to PR kern/40605; it has been noted by GNATS.
|
| From: Michael Stapelberg <michael+netbsd@stapelberg.de>
| To: gnats-bugs@NetBSD.org
| Cc:
| Subject: Re: kern/40605
| Date: Sat, 4 Apr 2009 19:01:50 +0200
|
| Hi,
|
| I just wanted to add that I can reproduce this, too. Packets sent from the
| host itself arrive fine, but forwarded packets have a wrong version header (9
| instead of 6).
|
| Can someone please have a look into this? I really need IPv6 for my daily work
| and this is kind of a show-stopper right now.
|
| Best regards,
| Michael
Can you see if going back to revision 1.75 fixes it?
christos
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40605
Date: Sun, 5 Apr 2009 07:37:16 +0200
Hi Christos,
actually I’m using revision 1.75, so, no, this does not fix it.
Best regards,
Michael
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40605
Date: Mon, 6 Apr 2009 23:31:22 +0200
Hi,
I just confirmed with Julien that this problem apparently affects only
re(4). He is using re(4) and I'm using re(4) since my old mainboard died.
On the old mainboard, with wm(4), this setup did not make any trouble.
I just upgraded rtl8169.c to the version in -current, it didn't help.
My card is the following:
re0 at pci3 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
re0: interrupting at ioapic0 pin 16
re0: Ethernet address 00:1f:d0:a3:e4:35
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
ppb3 at pci0 dev 28 function 5: vendor 0x8086 product 0x3a4a (rev. 0x00)
pci4 at ppb3 bus 4
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
re1 at pci4 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
re1: interrupting at ioapic0 pin 17
re1: Ethernet address 00:1f:d0:a3:e4:45
re1: using 256 tx descriptors
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
The mainboard is:
Gigabyte Technology Co., Ltd. EP45-DS3 ( )
Julien's mainboard is:
INTEL D945GCLF2 iAtomPro.330
Julien's dmesg is:
re0 at pci1 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
re0: interrupting at ioapic0 pin 16
re0: Unknown revision (0x3c400000)
re0: Ethernet address 00:1c:c0:9b:7a:8f
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
Best regards,
Michael
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40605
Date: Tue, 7 Apr 2009 01:14:44 +0200
Hi,
after some more debugging I found out that the bug is in in_delayed_cksum() in
sys/netinet/ip_output.c.
In the beginning of the function (right after using ip = mtod(…)), the ip6_hdr's
ip6_vfc field is set to 96, which is the correct value. Afterwards, that is before
returning, the field is set to some seemingly random value (probably related to
the checksum).
This is probably triggered by re(4) as it is a card which does not support
hardware checksumming.
The triggering code for in_delayed_csum is very likely this one:
if (m->m_pkthdr.csum_flags & (M_CSUM_TCPv4|M_CSUM_UDPv4)) {
if (IN_NEED_CHECKSUM(ifp,
m->m_pkthdr.csum_flags & (M_CSUM_TCPv4|M_CSUM_UDPv4))) {
in_delayed_cksum(m);
}
m->m_pkthdr.csum_flags &= ~(M_CSUM_TCPv4|M_CSUM_UDPv4);
}
I'm asking myself if M_CSUM_TCPv4 or M_CSUM_UDPv4 should be set on IP-packets
containing IPv6 packets. Is this bug more fundamental?
By applying the following patch, the bug is worked around:
--- a/ip_output.c
+++ b/ip_output.c
@@ -1067,6 +1067,13 @@ in_delayed_cksum(struct mbuf *m)
u_int16_t csum, offset;
ip = mtod(m, struct ip *);
+
+ /* XXX: FIXME: Don't touch IPv6-in-IPv4 packets as long as the checksum
+ * flag is wrongly set for them. This overwrites the version field of a
+ * packet if we don't return here. */
+ if (ip->ip_p == IPPROTO_IPV6)
+ return;
+
offset = ip->ip_hl << 2;
csum = in4_cksum(m, 0, offset, ntohs(ip->ip_len) - offset);
if (csum == 0 && (m->m_pkthdr.csum_flags & M_CSUM_UDPv4) != 0)
Best regards,
Michael
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/40605
Date: Mon, 20 Apr 2009 21:07:02 +0200
Hi,
I just wanted to add that I cannot reproduce this problem on my Realtek
DGE-528T which is another card supported by re(4).
By reading some more of the code, I think that the crong checksum flag is set
when receiving the packet, to be specific in sys/dev/ic/rtl8169.c in
re_rxeof(), at the end of the function. What seems a bit odd to me is that the
protocol family is not checked, which is done in other drivers. Instead, the
flags for IPv4 are just added, if the hardware says so. Probably the cards
affected by this bug *do* say so.
I will further debug this in one or two weeks, when I get another mainboard
with this chip, if no one has this chip somewhere else.
Best regards,
Michael
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-pr@pool.julien-oster.de, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/40605
Date: Tue, 21 Apr 2009 20:34:55 +0900
> From: Michael Stapelberg <michael+netbsd@stapelberg.de>
> By reading some more of the code, I think that the crong checksum flag is set
> when receiving the packet, to be specific in sys/dev/ic/rtl8169.c in
> re_rxeof(), at the end of the function. What seems a bit odd to me is that the
> protocol family is not checked, which is done in other drivers. Instead, the
> flags for IPv4 are just added, if the hardware says so. Probably the cards
> affected by this bug *do* say so.
It looks newer RTL8168C/8111C chips also recognize IPv6 packets
(and support IPv6/TCPv6/UDPv6 hwcsums?), so driver should check
not only PROTOID but also IPV4 bit in RX descs for M_CSUM_TCPv4
and M_CSUM_UDPv4 on those RTKQ_DESCV2 variants.
How about the attached patch (against -current)?
Note netbsd-5 doesn't have hwcsum support for those newer chips (yet),
so you also have to pull the following revisions:
rtl8169.c: 1.109, 1.110, 1.111, 1.112, 1.113
rtl81x9reg.h: 1.34, 1.35
rtl81x9var.h: 1.43, 1.44, 1.45
Index: rtl8169.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/rtl8169.c,v
retrieving revision 1.116
diff -u -r1.116 rtl8169.c
--- rtl8169.c 13 Apr 2009 12:38:06 -0000 1.116
+++ rtl8169.c 21 Apr 2009 11:20:13 -0000
@@ -1272,25 +1272,49 @@
m->m_pkthdr.rcvif = ifp;
/* Do RX checksumming */
+ if ((sc->sc_quirk & RTKQ_DESCV2) == 0) {
+ /* Check IP header checksum */
+ if ((rxstat & RE_RDESC_STAT_PROTOID) != 0) {
+ m->m_pkthdr.csum_flags |= M_CSUM_IPv4;
+ if (rxstat & RE_RDESC_STAT_IPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_IPv4_BAD;
+ }
- /* Check IP header checksum */
- if ((rxstat & RE_RDESC_STAT_PROTOID) != 0 &&
- ((sc->sc_quirk & RTKQ_DESCV2) == 0 ||
- (rxvlan & RE_RDESC_VLANCTL_IPV4) != 0)) {
- m->m_pkthdr.csum_flags |= M_CSUM_IPv4;
- if (rxstat & RE_RDESC_STAT_IPSUMBAD)
- m->m_pkthdr.csum_flags |= M_CSUM_IPv4_BAD;
- }
-
- /* Check TCP/UDP checksum */
- if (RE_TCPPKT(rxstat)) {
- m->m_pkthdr.csum_flags |= M_CSUM_TCPv4;
- if (rxstat & RE_RDESC_STAT_TCPSUMBAD)
- m->m_pkthdr.csum_flags |= M_CSUM_TCP_UDP_BAD;
- } else if (RE_UDPPKT(rxstat)) {
- m->m_pkthdr.csum_flags |= M_CSUM_UDPv4;
- if (rxstat & RE_RDESC_STAT_UDPSUMBAD)
- m->m_pkthdr.csum_flags |= M_CSUM_TCP_UDP_BAD;
+ /* Check TCP/UDP checksum */
+ if (RE_TCPPKT(rxstat)) {
+ m->m_pkthdr.csum_flags |= M_CSUM_TCPv4;
+ if (rxstat & RE_RDESC_STAT_TCPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_TCP_UDP_BAD;
+ } else if (RE_UDPPKT(rxstat)) {
+ m->m_pkthdr.csum_flags |= M_CSUM_UDPv4;
+ if (rxstat & RE_RDESC_STAT_UDPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_TCP_UDP_BAD;
+ }
+ } else {
+ /* Check IPv4 header checksum */
+ if ((rxstat & RE_RDESC_STAT_PROTOID) != 0 &&
+ (rxvlan & RE_RDESC_VLANCTL_IPV4) != 0) {
+ m->m_pkthdr.csum_flags |= M_CSUM_IPv4;
+ if (rxstat & RE_RDESC_STAT_IPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_IPv4_BAD;
+
+ /* Check TCPv4/UDPv4 checksum */
+ if (RE_TCPPKT(rxstat)) {
+ m->m_pkthdr.csum_flags |= M_CSUM_TCPv4;
+ if (rxstat & RE_RDESC_STAT_TCPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_TCP_UDP_BAD;
+ } else if (RE_UDPPKT(rxstat)) {
+ m->m_pkthdr.csum_flags |= M_CSUM_UDPv4;
+ if (rxstat & RE_RDESC_STAT_UDPSUMBAD)
+ m->m_pkthdr.csum_flags |=
+ M_CSUM_TCP_UDP_BAD;
+ }
+ }
}
if (rxvlan & RE_RDESC_VLANCTL_TAG) {
---
Izumi Tsutsui
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, kern-bug-people@NetBSD.org,
netbsd-pr@pool.julien-oster.de
Subject: Re: kern/40605
Date: Tue, 21 Apr 2009 20:52:00 +0200
Hi Izumi,
Thanks for taking time to help with this.
Unfortunately, your patch does not fix the problem. I want to emphasize that I
have an 8168B/8111B card, so RTKQ_DESCV2 will not be set. In your patch, for
the if-part, you still only check RE_RDESC_STAT_PROTOID, but not
RE_DESC_VLANCTL_IPV4.
Is this intended? Or was it a mix-up, maybe related to revision 1.113 of
rtl8169.c?
Best regards,
Michael
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
netbsd-pr@pool.julien-oster.de, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/40605
Date: Wed, 22 Apr 2009 07:58:46 +0900
> Unfortunately, your patch does not fix the problem. I want to emphasize that I
> have an 8168B/8111B card, so RTKQ_DESCV2 will not be set. In your patch, for
> the if-part, you still only check RE_RDESC_STAT_PROTOID, but not
> RE_DESC_VLANCTL_IPV4.
Hmm, 8168B and C have the same PCI device ID, so we have to check
hwrev values to identify them. Julien's one is 8168C_SPIN2:
>> re0: Unknown revision (0x3c400000)
What exact hwrev value is yours?
If !DESCV2 8168 chips actually could set PROTOID even for non-IPv4 packets,
we might also have to check ip->ip_p in IP header..
> Is this intended? Or was it a mix-up, maybe related to revision 1.113 of
> rtl8169.c?
BTW, does ip4csum/tcp4csum/udp4csum work on yours?
---
Izumi Tsutsui
From: Michael Stapelberg <michael+netbsd@stapelberg.de>
To: gnats-bugs@NetBSD.org
Cc: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, kern-bug-people@NetBSD.org,
netbsd-pr@pool.julien-oster.de
Subject: Re: kern/40605
Date: Wed, 22 Apr 2009 09:29:58 +0200
Hi,
> What exact hwrev value is yours?
In dmesg, I don't get a hwrev value. All I get is this:
ppb2 at pci0 dev 28 function 4: vendor 0x8086 product 0x3a48 (rev. 0x00)
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
re0 at pci3 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
re0: interrupting at ioapic0 pin 16
re0: Ethernet address 00:1f:d0:a3:e4:35
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
ppb3 at pci0 dev 28 function 5: vendor 0x8086 product 0x3a4a (rev. 0x00)
pci4 at ppb3 bus 4
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
re1 at pci4 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
re1: interrupting at ioapic0 pin 17
re1: Ethernet address 00:1f:d0:a3:e4:45
re1: using 256 tx descriptors
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 2
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> If !DESCV2 8168 chips actually could set PROTOID even for non-IPv4 packets,
> we might also have to check ip->ip_p in IP header..
I'll get the new boards this evening, I'll have a look if they do that.
> BTW, does ip4csum/tcp4csum/udp4csum work on yours?
I only tried that during debugging the IPv6-issue, but at least it didn't
mangle IPv4 packets. Again, I'll have a look this evening.
Best regards,
Michael
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
netbsd-pr@pool.julien-oster.de, michael+netbsd@stapelberg.de,
tsutsui@ceres.dti.ne.jp
Subject: Re: kern/40605
Date: Wed, 22 Apr 2009 20:04:08 +0900
> From: Michael Stapelberg <michael+netbsd@stapelberg.de>
> > What exact hwrev value is yours?
> In dmesg, I don't get a hwrev value. All I get is this:
Hmm we should put a printf for hwrev as well as FreeBSD?
According to Gigabyte's manual, EP45-DS3 has two RTL8111C
so it should be 0x3c000000 (RTK_HWREV_8168C) and should have DESCV2.
> re0 at pci3 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet (rev. 0x02)
I'll remove "B" suffix from the attach message because
all 8168 PCIe variants (8168/B/C/CP/D) have the same PCI device ID
(though they seem to have the different revision IDs).
---
Izumi Tsutsui
Responsible-Changed-From-To: kern-bug-people->tsutsui
Responsible-Changed-By: tsutsui@NetBSD.org
Responsible-Changed-When: Mon, 04 May 2009 00:43:24 +0900
Responsible-Changed-Why:
I'll take this if it's re(4)'s problem.
State-Changed-From-To: open->feedback
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Mon, 04 May 2009 00:43:24 +0900
State-Changed-Why:
awaiting feedback.
From: Izumi Tsutsui <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40605 CVS commit: src/sys/dev/ic
Date: Sun, 31 May 2009 05:10:47 +0000
Module Name: src
Committed By: tsutsui
Date: Sun May 31 05:10:47 UTC 2009
Modified Files:
src/sys/dev/ic: rtl8169.c
Log Message:
Two fixes for RX hwcsum on DESCV2 chips:
* On checking TCPv4/UDPv4 RX checksum on DESCV2 chips, also check
RE_RDESC_VLANCTL_IPV4 bit because those DESCV2 chips may also recognize
IPv6 packets and set RE_PROTOID_TCPIP or RE_PROTOID_UDPIP bits for
TCPv6/UDPv6 packets. This may fix PR kern/40605.
* According to Realtek's Linux driver, DESCV2 chips don't set RE_PROTOID_IP
for non-TCP/UDP IP packets (set only RE_RDESC_VLANCTL_IPV[46]) so
remove PROTOID check for IPv4 RX cheksum on DESCV2 chips.
To generate a diff of this commit:
cvs rdiff -u -r1.120 -r1.121 src/sys/dev/ic/rtl8169.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40605 CVS commit: [netbsd-5] src/sys/dev
Date: Fri, 19 Jun 2009 21:51:44 +0000
Module Name: src
Committed By: snj
Date: Fri Jun 19 21:51:44 UTC 2009
Modified Files:
src/sys/dev/ic [netbsd-5]: rtl8169.c rtl81x9reg.h rtl81x9var.h
src/sys/dev/mii [netbsd-5]: rgephy.c
src/sys/dev/pci [netbsd-5]: if_re_pci.c
Log Message:
Pull up following revision(s) (requested by tsutsui in ticket #821):
sys/dev/ic/rtl8169.c: revisions 1.107, 1.114-1.119, 1.121
sys/dev/ic/rtl81x9reg.h: revisions 1.36-1.39
sys/dev/ic/rtl81x9var.h: revision 1.47
sys/dev/mii/rgephy.c: revision 1.27 via patch
sys/dev/pci/if_re_pci.c: revision 1.36
remove extra semicolons.
--
Add HWREV values of RTL8168CP and RTL8168D. From FreeBSD.
XXX: needs more quirk handling after wakeup for newer chips.
--
Add HWREV of RTL8102EL variant. From FUKAUMI Naoki.
--
Assume an unknown HWREV chip has the same features with the latest one.
--
Remove suffix "B" from rtk_name of PCI_PRODUCT_REALTEK_RT8168 devices.
All 8168/8111 variants (8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP)
have the same PCI device ID.
--
Remove magic reset sequence except wakeup for rev 2 chips which breaks 8111D.
Problem reported and fix confirmed by Thomas Bieg on current-users.
Also tested on 8111C (no bad side effect) by several users privately.
--
Pull some changes for newer chips from FreeBSD:
- pull MACSTAT and CMDSTOP quirks for 8168/8111 chips
- always set CPLUSCMD_PCI_MRW on reset
- set VLANSTRIP and RXCSUM_ENB bits on CPLUS register per if_capenable
Tested on 8111C and 8111D by several users, and
no bad side effect on my old 8169S.
--
Remove unused sc_rev settings (all quirks are handled by sc_quirk)
and merge HWREV cases which have the same quirks.
--
- rename RTK_HWREV_8102EL_SPIN2 -> RTK_HWREV_8103E
- add a HWREV value for 8168DP
Per Realtek's Linux drivers.
--
Two fixes for RX hwcsum on DESCV2 chips:
* On checking TCPv4/UDPv4 RX checksum on DESCV2 chips, also check
RE_RDESC_VLANCTL_IPV4 bit because those DESCV2 chips may also recognize
IPv6 packets and set RE_PROTOID_TCPIP or RE_PROTOID_UDPIP bits for
TCPv6/UDPv6 packets. This may fix PR kern/40605.
* According to Realtek's Linux driver, DESCV2 chips don't set RE_PROTOID_IP
for non-TCP/UDP IP packets (set only RE_RDESC_VLANCTL_IPV[46]) so
remove PROTOID check for IPv4 RX cheksum on DESCV2 chips.
To generate a diff of this commit:
cvs rdiff -u -r1.105.4.7 -r1.105.4.8 src/sys/dev/ic/rtl8169.c
cvs rdiff -u -r1.32.4.3 -r1.32.4.4 src/sys/dev/ic/rtl81x9reg.h
cvs rdiff -u -r1.41.12.4 -r1.41.12.5 src/sys/dev/ic/rtl81x9var.h
cvs rdiff -u -r1.21 -r1.21.10.1 src/sys/dev/mii/rgephy.c
cvs rdiff -u -r1.35 -r1.35.4.1 src/sys/dev/pci/if_re_pci.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Manuel Bouyer <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40605 CVS commit: [netbsd-4] src/sys/dev
Date: Tue, 18 Aug 2009 09:46:51 +0000
Module Name: src
Committed By: bouyer
Date: Tue Aug 18 09:46:51 UTC 2009
Modified Files:
src/sys/dev/ic [netbsd-4]: rtl8169.c rtl81x9reg.h rtl81x9var.h
src/sys/dev/mii [netbsd-4]: rgephy.c rgephyreg.h
src/sys/dev/pci [netbsd-4]: if_re_pci.c
Log Message:
Pull up following revision(s) (requested by tsutsui in ticket #1339):
sys/dev/ic/rtl8169.c: revisions 1.107, 1.114, 1.115, 1.116,
1.117 (via patch), 1.118 (via patch),
1.119, 1.121
sys/dev/ic/rtl81x9reg.h: revisions 1.36, 1.37, 1.38, 1.39
sys/dev/ic/rtl81x9var.h: revision 1.47
sys/dev/mii/rgephy.c: revisions 1.16, 1.18, 1.19, 1.27 (via patch)
sys/dev/mii/rgephyreg.h: revision 1.3
sys/dev/pci/if_re_pci.c: revision 1.36
- add support for RTL8211B(L) to rgephy(4)
- add a wakeup instruction for rgephy(4) on newer re(4) chips
- detect RTL8169CP, RTL8168D/8111D, and RTL8103E variants
- fix rgephy(4) problem on RTL8111D reported on current-users:
http://mail-index.NetBSD.org/current-users/2009/04/12/msg008977.html
http://mail-index.NetBSD.org/current-users/2009/04/19/msg009096.html
- pull more quirk handling from FreeBSD
- fix RX hwcksum for DESCV2 chips for PR kern/40605
- remove "B" suffix from RTL8168 device names in attach message
To generate a diff of this commit:
cvs rdiff -u -r1.72.2.10 -r1.72.2.11 src/sys/dev/ic/rtl8169.c
cvs rdiff -u -r1.25.2.5 -r1.25.2.6 src/sys/dev/ic/rtl81x9reg.h
cvs rdiff -u -r1.37.2.2 -r1.37.2.3 src/sys/dev/ic/rtl81x9var.h
cvs rdiff -u -r1.15 -r1.15.2.1 src/sys/dev/mii/rgephy.c
cvs rdiff -u -r1.2 -r1.2.2.1 src/sys/dev/mii/rgephyreg.h
cvs rdiff -u -r1.21.2.5 -r1.21.2.6 src/sys/dev/pci/if_re_pci.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->closed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Sun, 25 Oct 2009 00:15:51 +0900
State-Changed-Why:
No feedback ~six months. Assume fixed.
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@NetBSD.org, gnats-admin@NetBSD.org, netbsd-pr@pool.julien-oster.de,
tsutsui@ceres.dti.ne.jp
Subject: Re: kern/40605 (forwarded IPv6 TCP packets get mangled by gif0 interface)
Date: Sun, 15 Nov 2009 05:12:41 +0900
> Synopsis: forwarded IPv6 TCP packets get mangled by gif0 interface
Just FYI, but the following gif fix might also affect this PR.
http://mail-index.NetBSD.org/source-changes/2009/11/11/msg003069.html
>> Clear cksum flags before any further processing like ip_forward does.
>> Many drivers set the UDP/TCP v4 flags even for v6 traffic and if the
>> packet is encapsulated with gif, the IPv6 header would get corrupted by
>> ip_output. Patch suggested by bad@
---
Izumi Tsutsui
>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