From nobody@FreeBSD.org  Fri Mar 12 12:53:44 2010
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 BEEEE106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 12 Mar 2010 12:53:44 +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 783A58FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 12 Mar 2010 12:53:44 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o2CCriQ8017466
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 12 Mar 2010 12:53:44 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o2CCrhC9017454;
	Fri, 12 Mar 2010 12:53:43 GMT
	(envelope-from nobody)
Message-Id: <201003121253.o2CCrhC9017454@www.freebsd.org>
Date: Fri, 12 Mar 2010 12:53:43 GMT
From: Steven Noonan <steven@uplinklabs.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: TCP transfer corruption using if_re
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         144689
>Category:       kern
>Synopsis:       [re] TCP transfer corruption using if_re
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 12 13:00:13 UTC 2010
>Closed-Date:    Thu Jan 20 03:01:35 UTC 2011
>Last-Modified:  Thu Jan 20 03:01:35 UTC 2011
>Originator:     Steven Noonan
>Release:        8.0-RELEASE-p2
>Organization:
>Environment:
FreeBSD xerxes.uplinklabs.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan  5 16:02:27 UTC 2010     root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
I was attempting to test git-daemon, and discovered that doing 'git clone' remotely is failing every time, with either a zlib decompression error or a protocol error. The git daemon uses TCP to serve its data.

If I use 'git clone' using the git protocol over a tunnel created with 'ssh -L', the clone works without any errors.

The only thing that makes a difference is either tunneling via SSH or using the machine's onboard NIC instead (which uses if_fxp). Those two methods work fine. But using the NIC which utilizes the 'if_re' driver is not working properly. I'm not certain if it makes a difference, but the NIC is connected via a cardbus controller.

It's also worth noting that this problem has never cropped up before using any other operating system, so it seems extremely unlikely to be a hardware issue.

I'm not certain what data would be relevant for this issue, so please let me know what sort of debugging I should do to help narrow down the issue. And thank you in advance for your help!
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Mar 12 13:19:14 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144689 
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Fri Mar 12 17:53:37 UTC 2010 
State-Changed-Why:  
This looks like Rx checksum offloading issue. Would you try 
disabling Rx checksum offloading and test it again? 
#ifconfig re0 -rxcsum 
Also show me dmesg output(re(4) related part). 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Fri Mar 12 17:53:37 UTC 2010 
Responsible-Changed-Why:  
Mine. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144689 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Steven Noonan <steven@uplinklabs.net>
Cc: yongari@freebsd.org, freebsd-net@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Tue, 16 Mar 2010 11:23:22 -0700

 On Sat, Mar 13, 2010 at 04:18:30AM -0800, Steven Noonan wrote:
 > On Fri, Mar 12, 2010 at 9:57 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 > > On Fri, Mar 12, 2010 at 4:24 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 > >> On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 > >>> On Fri, Mar 12, 2010 at 9:54 AM, ??<yongari@freebsd.org> wrote:
 > >>>> Synopsis: [re] TCP transfer corruption using if_re
 > >>>>
 > >>>> State-Changed-From-To: open->feedback
 > >>>> State-Changed-By: yongari
 > >>>> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
 > >>>> State-Changed-Why:
 > >>>> This looks like Rx checksum offloading issue. Would you try
 > >>>> disabling Rx checksum offloading and test it again?
 > >>>> #ifconfig re0 -rxcsum
 > >>>> Also show me dmesg output(re(4) related part).
 > >>>>
 > >>>>
 > >>>> Responsible-Changed-From-To: freebsd-net->yongari
 > >>>> Responsible-Changed-By: yongari
 > >>>> Responsible-Changed-When: Fri Mar 12 17:53:37 UTC 2010
 > >>>> Responsible-Changed-Why:
 > >>>> Mine.
 > >>>>
 > >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=144689
 > >>>>
 > >>>
 > >>> Hmm. Disabling Rx checksum offloading helped for one clone process,
 > >>> but then this showed up in dmesg during my second test (it seems to be
 > >>> doing this regularly for some reason):
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>>
 > >>> And no, the cable isn't loose or something. It just decides to take
 > >>> the interface down and put it back up.
 > >>>
 > >>> Here's the rest of 'dmesg | grep re0':
 > >>>
 > >>> firewire0: <IEEE1394(FireWire) bus> on fwohci0
 > >>> dcons_crom0: <dcons configuration ROM> on firewire0
 > >>> fwe0: <Ethernet over FireWire> on firewire0
 > >>> fwip0: <IP over FireWire> on firewire0
 > >>> firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) ??(me)
 > >>> firewire0: bus manager 0
 > >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
 > >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
 > >>> cardbus0
 > >>> re0: Chip rev. 0x10000000
 > >>> re0: MAC rev. 0x00000000
 > >>> miibus1: <MII bus> on re0
 > >>> re0: Ethernet address: 00:18:4d:6e:c0:29
 > >>> re0: [FILTER]
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: detached
 > >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
 > >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
 > >>> cardbus0
 > >>> re0: Chip rev. 0x10000000
 > >>> re0: MAC rev. 0x00000000
 > >>> miibus1: <MII bus> on re0
 > >>> re0: Ethernet address: 00:18:4d:6e:c0:29
 > >>> re0: [FILTER]
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: PHY read failed
 > >>> re0: link state changed to DOWN
 > >>> re0: link state changed to UP
 > >>> re0: PHY read failed
 > >>>
 > >>> - Steven
 > >>>
 > >>
 > >> I should note that the connection was _lost_ during the second test above.
 > >>
 > >> I also tested again, and it looks like it added another "re0: PHY read
 > >> failed" before silently dropping the connection.
 > >>
 > >> - Steven
 > >>
 > >
 > > I did a couple captures with Wireshark on the client end. One is with
 > > rxcsum enabled on the machine running git-daemon, one is without
 > > rxcsum.
 > >
 > > http://www.uplinklabs.net/~tycho/files/git-cap-norxcsum.bz2
 > > http://www.uplinklabs.net/~tycho/files/git-cap.bz2
 > >
 > > Obviously, you can look at the data yourself and make more sense of
 > > it, but here are things I noticed in the captures:
 > >
 > > With rxcsum:
 > > - There are some silent problems that occur in the middle of the
 > > capture. Client-to-server: 'TCP ACKed lost segment' a few times, then
 > > 'TCP previous segment lost'. This happens multiple times during the
 > > capture (before 'git-upload-pack' starts sending data).
 > > - Occasional 'TCP window update's. These are highlighted in black for
 > > reasons unknown to me. It seems like this would be normal.
 > > - The server calls 'git-upload-pack' and we start seeing a large
 > > number of client-to-server TCP RST flags being sent and then the
 > > connection gets closed due to some detected data corruption in the
 > > transfer.
 > >
 > > Without rxcsum:
 > > - About the same amount of client-to-server 'TCP ACKed lost segment's.
 > > - 'git-upload-pack' kicks in and things get _really_ hairy. 'TCP Dup
 > > ACK' detected by the client many many times.
 > > - Finally, a series of 'TCP retransmission's from server to client
 > > happen (which is where the connection hangs).
 > > - I closed the connection which triggered the final two 'TCP RST's.
 > >
 > > Also, I forgot to note in my original report that I checked if there
 > > was packet loss by using a ping flood, and one packet in the 1.5
 > > million packets sent was lost. But I'm not sure whether it's
 > > checksumming the data of these packets, so they could be coming back
 > > with perfectly valid ICMP headers but corrupted data.
 > >
 > 
 > Also, hilariously horrible hack:
 > 
 > - On the server machine, start git-daemon listening on 127.0.0.1:9418.
 > - On the server machine, run 'ssh -L <public IP>:9418:127.0.0.1:9418
 > user@localhost'.
 > 
 > Then remote git clones work as expected. Very strange. It will have to
 > do until I get a less insane solution.
 > 
 
 The real issue looks like PHY read failure which can result in
 unexpected behavior. I don't see rgephy(4) related message here,
 would you show me the output of "devinfo -rv | grep phy"?
 By chance are you using PCMCIA ethernet controller?
 
 > I don't understand why it makes a difference. Is git-daemon using TCP
 > socket options that causes this network interface driver to
 > malfunction?
 > 
 
 No, I don't think so. It would be a bug in driver.
 
 > - Steven

From: Steven Noonan <steven@uplinklabs.net>
To: pyunyh@gmail.com
Cc: yongari@freebsd.org, freebsd-net@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Tue, 16 Mar 2010 12:31:22 -0700

 On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > On Sat, Mar 13, 2010 at 04:18:30AM -0800, Steven Noonan wrote:
 >> On Fri, Mar 12, 2010 at 9:57 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 >> > On Fri, Mar 12, 2010 at 4:24 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 >> >> On Fri, Mar 12, 2010 at 4:19 PM, Steven Noonan <steven@uplinklabs.net> wrote:
 >> >>> On Fri, Mar 12, 2010 at 9:54 AM, ??<yongari@freebsd.org> wrote:
 >> >>>> Synopsis: [re] TCP transfer corruption using if_re
 >> >>>>
 >> >>>> State-Changed-From-To: open->feedback
 >> >>>> State-Changed-By: yongari
 >> >>>> State-Changed-When: Fri Mar 12 17:53:37 UTC 2010
 >> >>>> State-Changed-Why:
 >> >>>> This looks like Rx checksum offloading issue. Would you try
 >> >>>> disabling Rx checksum offloading and test it again?
 >> >>>> #ifconfig re0 -rxcsum
 >> >>>> Also show me dmesg output(re(4) related part).
 >> >>>>
 >> >>>>
 >> >>>> Responsible-Changed-From-To: freebsd-net->yongari
 >> >>>> Responsible-Changed-By: yongari
 >> >>>> Responsible-Changed-When: Fri Mar 12 17:53:37 UTC 2010
 >> >>>> Responsible-Changed-Why:
 >> >>>> Mine.
 >> >>>>
 >> >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=144689
 >> >>>>
 >> >>>
 >> >>> Hmm. Disabling Rx checksum offloading helped for one clone process,
 >> >>> but then this showed up in dmesg during my second test (it seems to be
 >> >>> doing this regularly for some reason):
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>>
 >> >>> And no, the cable isn't loose or something. It just decides to take
 >> >>> the interface down and put it back up.
 >> >>>
 >> >>> Here's the rest of 'dmesg | grep re0':
 >> >>>
 >> >>> firewire0: <IEEE1394(FireWire) bus> on fwohci0
 >> >>> dcons_crom0: <dcons configuration ROM> on firewire0
 >> >>> fwe0: <Ethernet over FireWire> on firewire0
 >> >>> fwip0: <IP over FireWire> on firewire0
 >> >>> firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) ??(me)
 >> >>> firewire0: bus manager 0
 >> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
 >> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
 >> >>> cardbus0
 >> >>> re0: Chip rev. 0x10000000
 >> >>> re0: MAC rev. 0x00000000
 >> >>> miibus1: <MII bus> on re0
 >> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
 >> >>> re0: [FILTER]
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: detached
 >> >>> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
 >> >>> port 0x1200-0x12ff mem 0x88000000-0x880001ff irq 18 at device 0.0 on
 >> >>> cardbus0
 >> >>> re0: Chip rev. 0x10000000
 >> >>> re0: MAC rev. 0x00000000
 >> >>> miibus1: <MII bus> on re0
 >> >>> re0: Ethernet address: 00:18:4d:6e:c0:29
 >> >>> re0: [FILTER]
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: PHY read failed
 >> >>> re0: link state changed to DOWN
 >> >>> re0: link state changed to UP
 >> >>> re0: PHY read failed
 >> >>>
 >> >>> - Steven
 >> >>>
 >> >>
 >> >> I should note that the connection was _lost_ during the second test above.
 >> >>
 >> >> I also tested again, and it looks like it added another "re0: PHY read
 >> >> failed" before silently dropping the connection.
 >> >>
 >> >> - Steven
 >> >>
 >> >
 >> > I did a couple captures with Wireshark on the client end. One is with
 >> > rxcsum enabled on the machine running git-daemon, one is without
 >> > rxcsum.
 >> >
 >> > http://www.uplinklabs.net/~tycho/files/git-cap-norxcsum.bz2
 >> > http://www.uplinklabs.net/~tycho/files/git-cap.bz2
 >> >
 >> > Obviously, you can look at the data yourself and make more sense of
 >> > it, but here are things I noticed in the captures:
 >> >
 >> > With rxcsum:
 >> > - There are some silent problems that occur in the middle of the
 >> > capture. Client-to-server: 'TCP ACKed lost segment' a few times, then
 >> > 'TCP previous segment lost'. This happens multiple times during the
 >> > capture (before 'git-upload-pack' starts sending data).
 >> > - Occasional 'TCP window update's. These are highlighted in black for
 >> > reasons unknown to me. It seems like this would be normal.
 >> > - The server calls 'git-upload-pack' and we start seeing a large
 >> > number of client-to-server TCP RST flags being sent and then the
 >> > connection gets closed due to some detected data corruption in the
 >> > transfer.
 >> >
 >> > Without rxcsum:
 >> > - About the same amount of client-to-server 'TCP ACKed lost segment's.
 >> > - 'git-upload-pack' kicks in and things get _really_ hairy. 'TCP Dup
 >> > ACK' detected by the client many many times.
 >> > - Finally, a series of 'TCP retransmission's from server to client
 >> > happen (which is where the connection hangs).
 >> > - I closed the connection which triggered the final two 'TCP RST's.
 >> >
 >> > Also, I forgot to note in my original report that I checked if there
 >> > was packet loss by using a ping flood, and one packet in the 1.5
 >> > million packets sent was lost. But I'm not sure whether it's
 >> > checksumming the data of these packets, so they could be coming back
 >> > with perfectly valid ICMP headers but corrupted data.
 >> >
 >>
 >> Also, hilariously horrible hack:
 >>
 >> - On the server machine, start git-daemon listening on 127.0.0.1:9418.
 >> - On the server machine, run 'ssh -L <public IP>:9418:127.0.0.1:9418
 >> user@localhost'.
 >>
 >> Then remote git clones work as expected. Very strange. It will have to
 >> do until I get a less insane solution.
 >>
 >
 > The real issue looks like PHY read failure which can result in
 > unexpected behavior. I don't see rgephy(4) related message here,
 > would you show me the output of "devinfo -rv | grep phy"?
 > By chance are you using PCMCIA ethernet controller?
 
 I am. It's a Netgear GA511. I think I said in my original post that it
 was connected via cardbus.
 
 xerxes ~ # devinfo -rv | grep phy
                     rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
                 inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
 
 
 >
 >> I don't understand why it makes a difference. Is git-daemon using TCP
 >> socket options that causes this network interface driver to
 >> malfunction?
 >>
 >
 > No, I don't think so. It would be a bug in driver.
 >
 >> - Steven
 >

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Steven Noonan <steven@uplinklabs.net>
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Tue, 16 Mar 2010 13:46:01 -0700

 On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 > On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 
 [...]
 
 > > The real issue looks like PHY read failure which can result in
 > > unexpected behavior. I don't see rgephy(4) related message here,
 > > would you show me the output of "devinfo -rv | grep phy"?
 > > By chance are you using PCMCIA ethernet controller?
 > 
 > I am. It's a Netgear GA511. I think I said in my original post that it
 > was connected via cardbus.
 > 
 > xerxes ~ # devinfo -rv | grep phy
 >                     rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
 >                 inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
 > 
 
 Ok, thanks for the info. Did the controller ever work before?
 Or you start seeing the issue on 8.0-RELEASE?

From: Steven Noonan <steven@uplinklabs.net>
To: pyunyh@gmail.com
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Tue, 16 Mar 2010 13:51:05 -0700

 On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrot=
 e:
 >
 > [...]
 >
 >> > The real issue looks like PHY read failure which can result in
 >> > unexpected behavior. I don't see rgephy(4) related message here,
 >> > would you show me the output of "devinfo -rv | grep phy"?
 >> > By chance are you using PCMCIA ethernet controller?
 >>
 >> I am. It's a Netgear GA511. I think I said in my original post that it
 >> was connected via cardbus.
 >>
 >> xerxes ~ # devinfo -rv | grep phy
 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rg=
 ephy0 pnpinfo oui=3D0x732 model=3D0x11 rev=3D0x3 at phyno=3D1
 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inphy0 pnpinfo o=
 ui=3D0xaa00 model=3D0x33 rev=3D0x0 at phyno=3D1
 >>
 >
 > Ok, thanks for the info. Did the controller ever work before?
 > Or you start seeing the issue on 8.0-RELEASE?
 >
 
 The last time I had FreeBSD on this machine was with 7.0-RELEASE (or
 7.1?), and I didn't have the GA511 at that time, so I don't know
 whether it worked before or not.
 
 (Incidentally, on my other machine, I get "PHY read failure" all the
 time with its Marvell Yukon controller [if_msk])
 
 - Steven

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Steven Noonan <steven@uplinklabs.net>
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org,
	imp@FreeBSD.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Tue, 16 Mar 2010 14:07:52 -0700

 On Tue, Mar 16, 2010 at 01:51:05PM -0700, Steven Noonan wrote:
 > On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 > >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > >
 > > [...]
 > >
 > >> > The real issue looks like PHY read failure which can result in
 > >> > unexpected behavior. I don't see rgephy(4) related message here,
 > >> > would you show me the output of "devinfo -rv | grep phy"?
 > >> > By chance are you using PCMCIA ethernet controller?
 > >>
 > >> I am. It's a Netgear GA511. I think I said in my original post that it
 > >> was connected via cardbus.
 > >>
 > >> xerxes ~ # devinfo -rv | grep phy
 > >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
 > >> ?? ?? ?? ?? ?? ?? ?? ?? inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
 > >>
 > >
 > > Ok, thanks for the info. Did the controller ever work before?
 > > Or you start seeing the issue on 8.0-RELEASE?
 > >
 > 
 > The last time I had FreeBSD on this machine was with 7.0-RELEASE (or
 > 7.1?), and I didn't have the GA511 at that time, so I don't know
 > whether it worked before or not.
 > 
 
 This is first report for PHY read error on RTL8169S. I have no idea
 what's happening here at this moment. I'm not familiar with
 cardbus(4) so it also makes me hard to identify the root cause of
 the issue. Maybe imp can give some instructions to debug.
 
 > (Incidentally, on my other machine, I get "PHY read failure" all the
 > time with its Marvell Yukon controller [if_msk])
 > 
 
 For msk(4) issue, please open new PR and let me know the PR number.

From: Steven Noonan <steven@uplinklabs.net>
To: pyunyh@gmail.com
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Sat, 20 Mar 2010 14:38:55 -0700

 On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrot=
 e:
 >
 > [...]
 >
 >> > The real issue looks like PHY read failure which can result in
 >> > unexpected behavior. I don't see rgephy(4) related message here,
 >> > would you show me the output of "devinfo -rv | grep phy"?
 >> > By chance are you using PCMCIA ethernet controller?
 >>
 >> I am. It's a Netgear GA511. I think I said in my original post that it
 >> was connected via cardbus.
 >>
 >> xerxes ~ # devinfo -rv | grep phy
 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rg=
 ephy0 pnpinfo oui=3D0x732 model=3D0x11 rev=3D0x3 at phyno=3D1
 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inphy0 pnpinfo o=
 ui=3D0xaa00 model=3D0x33 rev=3D0x0 at phyno=3D1
 >>
 >
 > Ok, thanks for the info. Did the controller ever work before?
 > Or you start seeing the issue on 8.0-RELEASE?
 >
 
 Uh, hm. This is weird, now I'm getting the problem not just using
 re(4), but also with fxp(4) (which is my on-board card). I don't think
 it's a driver bug here.
 
 Could this be a TCP stack bug?
 
 - Steven

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Steven Noonan <steven@uplinklabs.net>
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Wed, 22 Sep 2010 10:35:39 -0700

 On Sat, Mar 20, 2010 at 02:38:55PM -0700, Steven Noonan wrote:
 > On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 > >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > >
 > > [...]
 > >
 > >> > The real issue looks like PHY read failure which can result in
 > >> > unexpected behavior. I don't see rgephy(4) related message here,
 > >> > would you show me the output of "devinfo -rv | grep phy"?
 > >> > By chance are you using PCMCIA ethernet controller?
 > >>
 > >> I am. It's a Netgear GA511. I think I said in my original post that it
 > >> was connected via cardbus.
 > >>
 > >> xerxes ~ # devinfo -rv | grep phy
 > >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
 > >> ?? ?? ?? ?? ?? ?? ?? ?? inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
 > >>
 > >
 > > Ok, thanks for the info. Did the controller ever work before?
 > > Or you start seeing the issue on 8.0-RELEASE?
 > >
 > 
 > Uh, hm. This is weird, now I'm getting the problem not just using
 > re(4), but also with fxp(4) (which is my on-board card). I don't think
 > it's a driver bug here.
 > 
 > Could this be a TCP stack bug?
 > 
 
 How about using 8.1-RELEASE? Does it make any difference?
 
 > - Steven

From: Steven Noonan <steven@uplinklabs.net>
To: pyunyh@gmail.com
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org, yongari@freebsd.org
Subject: Re: kern/144689: [re] TCP transfer corruption using if_re
Date: Wed, 22 Sep 2010 12:05:01 -0700

 On Wed, Sep 22, 2010 at 10:35 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 > On Sat, Mar 20, 2010 at 02:38:55PM -0700, Steven Noonan wrote:
 >> On Tue, Mar 16, 2010 at 1:46 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 >> > On Tue, Mar 16, 2010 at 12:31:22PM -0700, Steven Noonan wrote:
 >> >> On Tue, Mar 16, 2010 at 11:23 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
 >> >
 >> > [...]
 >> >
 >> >> > The real issue looks like PHY read failure which can result in
 >> >> > unexpected behavior. I don't see rgephy(4) related message here,
 >> >> > would you show me the output of "devinfo -rv | grep phy"?
 >> >> > By chance are you using PCMCIA ethernet controller?
 >> >>
 >> >> I am. It's a Netgear GA511. I think I said in my original post that it
 >> >> was connected via cardbus.
 >> >>
 >> >> xerxes ~ # devinfo -rv | grep phy
 >> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x3 at phyno=1
 >> >> ?? ?? ?? ?? ?? ?? ?? ?? inphy0 pnpinfo oui=0xaa00 model=0x33 rev=0x0 at phyno=1
 >> >>
 >> >
 >> > Ok, thanks for the info. Did the controller ever work before?
 >> > Or you start seeing the issue on 8.0-RELEASE?
 >> >
 >>
 >> Uh, hm. This is weird, now I'm getting the problem not just using
 >> re(4), but also with fxp(4) (which is my on-board card). I don't think
 >> it's a driver bug here.
 >>
 >> Could this be a TCP stack bug?
 >>
 >
 > How about using 8.1-RELEASE? Does it make any difference?
 
 Don't have FreeBSD installed on that machine right now. Ended up going
 back to Linux. But I'll definitely pop in another hard drive and try
 it again within the next couple days.
 
 >> - Steven
 >
State-Changed-From-To: feedback->closed 
State-Changed-By: yongari 
State-Changed-When: Thu Jan 20 03:01:03 UTC 2011 
State-Changed-Why:  
Feedback timeout. 
If you happen to install FreeBSD and see the issue again please 
open a new PR. Thanks for reporting. 

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