From nobody@FreeBSD.org  Wed Dec 26 20:25: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 7447316A417
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 26 Dec 2007 20:25: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 694E513C468
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 26 Dec 2007 20:25: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 lBQKObhI036699
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 26 Dec 2007 20:24:37 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id lBQKObxG036698;
	Wed, 26 Dec 2007 20:24:37 GMT
	(envelope-from nobody)
Message-Id: <200712262024.lBQKObxG036698@www.freebsd.org>
Date: Wed, 26 Dec 2007 20:24:37 GMT
From: Sebastian <mueller.basti@web.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         119047
>Category:       kern
>Synopsis:       [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 26 20:30:04 UTC 2007
>Closed-Date:    Tue Mar 02 23:02:12 UTC 2010
>Last-Modified:  Tue Mar 02 23:02:12 UTC 2010
>Originator:     Sebastian
>Release:        FreeBSD 7.0-PRERELEASE
>Organization:
>Environment:
FreeBSD bluxx.mueller.mn 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Tue Dec 25 21:52:51 CET 2007 basti@bluxx.mueller.mn:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
Hi, 

I've got a RealTek 8168/8111B PCIe Gigabit Ethernet network chip,
connected to a 100mbit switch, DHCP is not working. Furthermore all
network traffic is getting worse after some time, I don't know how to
explain it exactly.

When starting the system, everthing works fine, but after 2-3 days
uptime SSH connections are breaking with "Garbled packet", Websites on
this apache Server are not displayed, pictures are 0 byte big when
opening in a browser, ftp connections are timing out (starting speed
with 2-3kbyte, normal speed is 5mbyte). After a reboot of the machine,
everything is working fine again, I tried to look if the hardware is
damaged, on debian everything worked fine.

Please help me solving this problem.



Dmesg:

Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-BETA4 #9: Mon Dec 17 06:08:19 CET 2007
    basti@bluxx.mueller.mn:/usr/obj/usr/src/sys/bluxx
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2999.99-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x40f33  Stepping = 3
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>
  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x1f<LAHF,CMP,SVM,ExtAPIC,CR8>
  Cores per package: 2
usable memory = 6400897024 (6104 MB)
avail memory  = 6184538112 (5898 MB)
ACPI APIC Table: <M S I  OEMAPIC >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.1> irqs 0-23 on motherboard
acpi0: <M S I OEMRSDT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, ddf00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: CLK_VAL field overlaps THT_EN bit
device_attach: acpi_throttle0 attach returned 6
cpu1: <ACPI CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1
pci1: <multimedia> at device 5.2 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> at device 7.0 on pci0
pci2: <ACPI PCI bus> on pcib2
re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2
re0: Using 2 MSI messages
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re0: Ethernet address: 00:19:db:d0:35:aa
re0: [FILTER]
re0: [FILTER]
atapci0: <ATI AHCI controller> port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfe7fe000-0xfe7fefff irq 16 at device 19.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfe7fd000-0xfe7fdfff irq 17 at device 19.1 on pci0
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: SMM does not respond, resetting
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.2 on pci0
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb2: OHCI version 1.0, legacy support
usb2: SMM does not respond, resetting
usb2: <OHCI (generic) USB controller> on ohci2
usb2: USB revision 1.0
uhub2: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xfe7fb000-0xfe7fbfff irq 17 at device 19.3 on pci0
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: SMM does not respond, resetting
usb3: <OHCI (generic) USB controller> on ohci3
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ohci4: <OHCI (generic) USB controller> mem 0xfe7fa000-0xfe7fafff irq 18 at device 19.4 on pci0
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: SMM does not respond, resetting
usb4: <OHCI (generic) USB controller> on ohci4
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfe7ff000-0xfe7ff0ff irq 19 at device 19.5 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb5: EHCI version 1.0
usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci0
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 10 ports with 10 removable, self powered
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP600 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib3: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci3: <ACPI PCI bus> on pcib3
acpi_button0: <Power Button> on acpi0
sio0: configured irq 3 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 3 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
orm0: <ISA Option ROM> at iomem 0xcd800-0xce7ff on isa0
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
ad4: 715404MB <Seagate ST3750640AS 3.AAE> at ata2-master SATA150
ad6: 715404MB <Seagate ST3750640AS 3.AAK> at ata3-master SATA150
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad4s1a


>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Jan 13 23:39:38 UTC 2008 
Responsible-Changed-Why:  
This does not sound amd64-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=119047 
Responsible-Changed-From-To: freebsd-bugs->yongari 
Responsible-Changed-By: remko 
Responsible-Changed-When: Mon Jan 14 07:29:12 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer. 

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

From: =?iso-8859-1?Q?Sebastian_M=FCller?= <sebastian-mueller@t-online.de>
To: <bug-followup@FreeBSD.org>,
	<mueller.basti@web.de>
Cc:  
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 18 Jan 2008 16:12:33 +0100

 I used ifconfig re0 -txcsum -rxcsum on FreeBSD-7.0-PRERELEASE cvsup'ed via
 RELENG_7
 
 It worked for a few days, then I had to expect the same problems. The
 problems are starting when transferring over a very long time.
 
 For example, running make world via SSH.
 

From: linimon@lonesome.com (Mark Linimon)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/119047: Not correct working RealTek 8168/8111B PCIe
Date: Sat, 26 Jan 2008 09:32:17 -0600

 Forwarding from posting to freebsd-amd64@:
 
 Date: Sat, 26 Jan 2008 15:02:00 +0200
 From: WSL <wsl77@mail.ru>
 
 try downgrade RAM size from 4G to 2G,
 on my 6.2 release it work
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Tue Feb 17 07:56:02 UTC 2009 
State-Changed-Why:  
Can you still reproduce this on recent FreeBSD release? 
I think 7-stable may have fixed the issue. 

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

From: Aristedes Maniatis <ari@ish.com.au>
To: bug-followup@FreeBSD.org,
 mueller.basti@web.de,
 yongari@FreeBSD.org
Cc: Jurgen Weber <jurgen@ish.com.au>
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 20 Feb 2009 14:24:27 +1100

 When was this problem fixed? We saw this problem in 7.1-release. Has  
 the fix been backported to a patch for 7.1 or is it only in 7-stable?  
 It would be nice if it was a patch for 7.1 since we are tracking  
 binaries with freebsd-update on our production machines.
 
 Ari Maniatis

From: Aristedes Maniatis <ari@ish.com.au>
To: pyunyh@gmail.com
Cc: bug-followup@FreeBSD.org,
 yongari@FreeBSD.org,
 Jurgen Weber <jurgen@ish.com.au>
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 20 Feb 2009 15:24:20 +1100

 On 20/02/2009, at 2:56 PM, Pyun YongHyeon wrote:
 
 > On Fri, Feb 20, 2009 at 02:24:27PM +1100, Aristedes Maniatis wrote:
 >> When was this problem fixed? We saw this problem in 7.1-release. Has
 >> the fix been backported to a patch for 7.1 or is it only in 7-stable?
 >
 > If you're suffering from re(4) instability issues on 7.1-RELEASE
 > please show me more details. Also it would be even better to let me
 > know dmesg output to narrow down affected controller revisions.
 > I think the original submitter's issue might be resolved in
 > 7-stable.
 >
 >> It would be nice if it was a patch for 7.1 since we are tracking
 >> binaries with freebsd-update on our production machines.
 >>
 >
 > It's easy, just copy if_re.c, if_rlreg.h and if_rl.c in
 > HEAD/7-stable to 7.1-RELEASE. It should build without problems.
 
 Thanks for that. When we have time we'll try again in 7.1 release and  
 if we are able to reproduce it, we'll try again in 7.1-stable. If we  
 still reproduce it, we'll send you dmesg and other info you need.
 
 Thanks
 Ari Maniatis
 
 
 -------------------------->
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
 
 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Aristedes Maniatis <ari@ish.com.au>
Cc: bug-followup@FreeBSD.org, mueller.basti@web.de, yongari@FreeBSD.org,
	Jurgen Weber <jurgen@ish.com.au>
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 20 Feb 2009 12:56:35 +0900

 On Fri, Feb 20, 2009 at 02:24:27PM +1100, Aristedes Maniatis wrote:
 > When was this problem fixed? We saw this problem in 7.1-release. Has  
 > the fix been backported to a patch for 7.1 or is it only in 7-stable?  
 
 If you're suffering from re(4) instability issues on 7.1-RELEASE
 please show me more details. Also it would be even better to let me
 know dmesg output to narrow down affected controller revisions.
 I think the original submitter's issue might be resolved in
 7-stable. 
 
 > It would be nice if it was a patch for 7.1 since we are tracking  
 > binaries with freebsd-update on our production machines.
 > 
 
 It's easy, just copy if_re.c, if_rlreg.h and if_rl.c in
 HEAD/7-stable to 7.1-RELEASE. It should build without problems.

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Aristedes Maniatis <ari@ish.com.au>
Cc: bug-followup@FreeBSD.org, yongari@FreeBSD.org,
	Jurgen Weber <jurgen@ish.com.au>
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 20 Feb 2009 13:42:42 +0900

 On Fri, Feb 20, 2009 at 03:24:20PM +1100, Aristedes Maniatis wrote:
 > 
 > On 20/02/2009, at 2:56 PM, Pyun YongHyeon wrote:
 > 
 > >On Fri, Feb 20, 2009 at 02:24:27PM +1100, Aristedes Maniatis wrote:
 > >>When was this problem fixed? We saw this problem in 7.1-release. Has
 > >>the fix been backported to a patch for 7.1 or is it only in 7-stable?
 > >
 > >If you're suffering from re(4) instability issues on 7.1-RELEASE
 > >please show me more details. Also it would be even better to let me
 > >know dmesg output to narrow down affected controller revisions.
 > >I think the original submitter's issue might be resolved in
 > >7-stable.
 > >
 > >>It would be nice if it was a patch for 7.1 since we are tracking
 > >>binaries with freebsd-update on our production machines.
 > >>
 > >
 > >It's easy, just copy if_re.c, if_rlreg.h and if_rl.c in
 > >HEAD/7-stable to 7.1-RELEASE. It should build without problems.
 > 
 > Thanks for that. When we have time we'll try again in 7.1 release and  
 > if we are able to reproduce it, we'll try again in 7.1-stable. If we  
 > still reproduce it, we'll send you dmesg and other info you need.
 > 
 
 I guess you may have seen different re(4) issue. Since re(4)
 supports too many variants it's very important to know exact
 controller model and detailed problem description. If you're using
 a system with more than 4GB memory that also should be mentioned in
 problem description. Just saying unstable or not working does not
 help diagnosing problems.

From: Aristedes Maniatis <ari@ish.com.au>
To: pyunyh@gmail.com
Cc: bug-followup@FreeBSD.org,
 yongari@FreeBSD.org,
 Jurgen Weber <jurgen@ish.com.au>
Subject: Re: kern/119047: [re] Not correct working RealTek 8168/8111B PCIe Gigabit Ethernet
Date: Fri, 20 Feb 2009 16:05:12 +1100

 On 20/02/2009, at 3:42 PM, Pyun YongHyeon wrote:
 
 > On Fri, Feb 20, 2009 at 03:24:20PM +1100, Aristedes Maniatis wrote:
 >>
 >> On 20/02/2009, at 2:56 PM, Pyun YongHyeon wrote:
 >>
 >>> On Fri, Feb 20, 2009 at 02:24:27PM +1100, Aristedes Maniatis wrote:
 >>>> When was this problem fixed? We saw this problem in 7.1-release.  
 >>>> Has
 >>>> the fix been backported to a patch for 7.1 or is it only in 7- 
 >>>> stable?
 >>>
 >>> If you're suffering from re(4) instability issues on 7.1-RELEASE
 >>> please show me more details. Also it would be even better to let me
 >>> know dmesg output to narrow down affected controller revisions.
 >>> I think the original submitter's issue might be resolved in
 >>> 7-stable.
 >>>
 >>>> It would be nice if it was a patch for 7.1 since we are tracking
 >>>> binaries with freebsd-update on our production machines.
 >>>>
 >>>
 >>> It's easy, just copy if_re.c, if_rlreg.h and if_rl.c in
 >>> HEAD/7-stable to 7.1-RELEASE. It should build without problems.
 >>
 >> Thanks for that. When we have time we'll try again in 7.1 release and
 >> if we are able to reproduce it, we'll try again in 7.1-stable. If we
 >> still reproduce it, we'll send you dmesg and other info you need.
 >>
 >
 > I guess you may have seen different re(4) issue. Since re(4)
 > supports too many variants it's very important to know exact
 > controller model and detailed problem description. If you're using
 > a system with more than 4GB memory that also should be mentioned in
 > problem description. Just saying unstable or not working does not
 > help diagnosing problems.
 
 Understand. The machine has exactly 4Gb and is running amd64 kernel.  
 The problems look very much like this bug report, but at this time I  
 just wanted to establish when your fixes got committed as there is no  
 connection between svn and the bug tracker. Then we'll be able to test  
 those fixes and report back if there is still a problem.
 
 Thanks
 Ari Maniatis
 
 
 
 -------------------------->
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
 
 
State-Changed-From-To: feedback->closed 
State-Changed-By: yongari 
State-Changed-When: Tue Mar 2 23:01:40 UTC 2010 
State-Changed-Why:  
Feedback timed out(> 1 year). After bus_dma(9) fixes for re(4), 
I believe re(4) can work with systems that has more than 4GB 
memory. If you still see the issue please open PR. 

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