Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Expired
|
Medium
|
|||
linux (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: linux-image-
Related to this bug:
http://
andres@
Description: Ubuntu jaunty (development branch)
Release: 9.04
Mainboard/
Network unstable on the latest kernel, worked fine on Intrepid Ibex.
Network goes down even though mii-tool still says negotiated, appears to be related to the network driver/adapter which is:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Dmesg output
[ 284.816023] ------------[ cut here ]------------
[ 284.816032] WARNING: at /build/
[ 284.816038] NETDEV WATCHDOG: eth2 (r8169): transmit timed out
[ 284.816042] Modules linked in: binfmt_misc i915 drm bridge stp bnep video output input_polldev smsc47m1 smsc47m192 hwmon_vid i2c_i801 sbp2 ieee1394 lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm ppdev snd_seq_dummy snd_seq_oss snd_seq_midi iTCO_wdt iTCO_vendor_support snd_rawmidi psmouse pcspkr snd_seq_midi_event serio_raw snd_seq snd_timer snd_seq_device parport_pc parport snd intel_agp soundcore snd_page_alloc agpgart usbhid usb_storage r8169 mii fbcon tileblit font bitblit softcursor
[ 284.816119] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.28-11-generic #37-Ubuntu
[ 284.816123] Call Trace:
[ 284.816135] [<c0139a60>] warn_slowpath+
[ 284.816143] [<c0156873>] ? getnstimeofday+
[ 284.816151] [<c0119aa3>] ? lapic_next_
[ 284.816158] [<c0159aaa>] ? clockevents_
[ 284.816165] [<c0156873>] ? getnstimeofday+
[ 284.816172] [<c02caded>] ? strlcpy+0x1d/0x60
[ 284.816180] [<c04313b2>] ? netdev_
[ 284.816186] [<c0445f19>] dev_watchdog+
[ 284.816193] [<c0156873>] ? getnstimeofday+
[ 284.816199] [<c0119aa3>] ? lapic_next_
[ 284.816206] [<c0159aaa>] ? clockevents_
[ 284.816214] [<c0143aa0>] run_timer_
[ 284.816220] [<c0445d00>] ? dev_watchdog+
[ 284.816226] [<c0445d00>] ? dev_watchdog+
[ 284.816233] [<c013f147>] __do_softirq+
[ 284.816240] [<c0152c36>] ? hrtimer_
[ 284.816246] [<c013f27d>] do_softirq+
[ 284.816253] [<c013f3f5>] irq_exit+0x55/0x90
[ 284.816259] [<c011a0ab>] smp_apic_
[ 284.816266] [<c0105318>] apic_timer_
[ 284.816274] [<c012f9ae>] ? finish_
[ 284.816281] [<c050106a>] schedule+
[ 284.816288] [<c013f35d>] ksoftirqd+
[ 284.816294] [<c013f280>] ? ksoftirqd+0x0/0x120
[ 284.816300] [<c014e8ac>] kthread+0x3c/0x70
[ 284.816306] [<c014e870>] ? kthread+0x0/0x70
[ 284.816312] [<c0105477>] kernel_
[ 284.816317] ---[ end trace ebee70bd161e4e23 ]---
[ 284.832839] r8169: eth2: link up
[ 296.832701] r8169: eth2: link up
[ 321.016744] r8169: eth2: link up
[ 681.016709] r8169: eth2: link up
[ 3231.016736] r8169: eth2: link up
It's stable for one hour if i force to 100mbps full duplex.
Other network gear working fine
Changed in linux: | |
status: | Unknown → Incomplete |
Jorge Suarez (andres-430) wrote : | #1 |
nebajoth (nebajoth) wrote : | #2 |
I'm having this same problem on Intrepid. Look how many have been dropped! Same hardware -- D945GCLF2 / Atom 330.
eth0 Link encap:Ethernet HWaddr 00:1c:c0:7e:82:41
inet addr:192.168.3.31 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::21c:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1414 errors:0 dropped:16291121954 overruns:0 frame:0
TX packets:976 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:111098 (111.0 KB) TX bytes:206672 (206.6 KB)
Refefer (refefer) wrote : | #3 |
I can also confirm this is happening. Same kernel, same hardware, same result.
Andreas Kern (kerna) wrote : | #4 |
i can confirm it too, also D945GCLF2
Andreas Kern (kerna) wrote : | #5 |
is there a way that the watchdog reacts faster? atm it takes several minutes until the pc is reachable again
Jorge Suarez (andres-430) wrote : Re: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty | #6 |
I rolled back to 8.04 seems fine there
On Mon, Jun 29, 2009 at 7:41 PM, dododoth <email address hidden> wrote:
> is there a way that the watchdog reacts faster? atm it takes several
> minutes until the pc is reachable again
>
> --
> Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on
> Jaunty
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
baskar (gbaskee) wrote : | #7 |
Dear Friends,
This mail not related to this bugs. I am in big confusion and hope that you
could clarify me.
I have 4 years of experience as linux admin, right now i am windows platform
and have no contact with linux server (due to crises we lost the linux
projects). I am yet to take RHCE exams.
Now my questions is whether spending money to RHCE exam is worth or taking
up a course for SUN Solaris or AIX. What do you suggest? Which is having
bright future and scope?
Please clarify my confusion. Your suggestion could be a turning point in my
life
Help me!!!!!!!!!!!!!!
Thanks
Baskar
On Tue, Jun 30, 2009 at 10:46 AM, Jorge Suarez <email address hidden> wrote:
> I rolled back to 8.04 seems fine there
>
> On Mon, Jun 29, 2009 at 7:41 PM, dododoth <email address hidden>
> wrote:
>
> > is there a way that the watchdog reacts faster? atm it takes several
> > minutes until the pc is reachable again
> >
> > --
> > Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on
> > Jaunty
> > https:/
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on
> Jaunty
> https:/
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
--
Regards,
Baskaran G
Andreas Kern (kerna) wrote : | #8 |
i could test it with 8.04 too, but i need ext4 support as my storage are 4x1.5TB disks in a Raid5 with ext4
so i think that's not an option for me, i was looking arround for some other options like using FreeNAS (FreeBSD based) or OpenFiler (linux based) but no ext4 support there.
so should i try debian or fedora? or do they use the same kernel+driver?
Laurent Bonnaud (laurent-bonnaud) wrote : | #9 |
I have the same problem on my Asus EeeBox:
- processor from /proc/cpuinfo:
Intel(R) Atom(TM) CPU N270 @ 1.60GHz
- network controller from lspci:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Here is a slightly different backtrace from a more recent kernel version:
[95952.971508] ------------[ cut here ]------------
[95952.971527] WARNING: at /build/
[95952.971543] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[95952.971554] Modules linked in: i915 drm binfmt_misc ppdev bridge stp bnep input_polldev nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc w83627ehf hwmon_vid lp parport snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi dvb_usb_dib0700 snd_rawmidi dib7000p dib7000m dvb_usb snd_seq_midi_event iTCO_wdt dvb_core snd_seq iTCO_vendor_support pcspkr snd_timer snd_seq_device dib3000mc dibx000_common psmouse dib0070 serio_raw video snd intel_agp joydev output soundcore agpgart snd_page_alloc eeepc_laptop hid_logitech ff_memless usb_storage usbhid r8169 mii raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear fbcon tileblit font bitblit softcursor
[95952.971871] Pid: 7, comm: ksoftirqd/1 Not tainted 2.6.28-13-server #45-Ubuntu
[95952.971885] Call Trace:
[95952.971911] [<c01411d0>] warn_slowpath+
[95952.971936] [<c0133e6c>] ? enqueue_
[95952.971960] [<c0139858>] ? dequeue_
[95952.971982] [<c02ce685>] ? __next_
[95952.972002] [<c0138a4d>] ? find_busiest_
[95952.972022] [<c013a31a>] ? check_preempt_
[95952.972041] [<c01304e3>] ? pull_task+0x43/0x60
[95952.972061] [<c013af38>] ? balance_
[95952.972080] [<c02d39ad>] ? strlcpy+0x1d/0x60
[95952.972099] [<c043b762>] ? netdev_
[95952.972116] [<c044fdc9>] dev_watchdog+
[95952.972136] [<c013520d>] ? update_
[95952.972156] [<c0139167>] ? load_balance_
[95952.972178] [<c014b6d0>] run_timer_
[95952.972198] [<c044fbb0>] ? dev_watchdog+
[95952.972217] [<c013713b>] ? finish_
[95952.972238] [<c044fbb0>] ? dev_watchdog+
[95952.972260] [<c01467d7>] __do_softirq+
[95952.972281] [<c014690d>] do_softirq+
[95952.972300] [<c014699a>] ksoftirqd+
[95952.972317] [<c0146910>] ? ksoftirqd+0x0/0x120
[95952.972335] [<c01564dc>] kthread+0x3c/0x70
[95952.972351] [<c01564a0>] ? kthread+0x0/0x70
[95952.972369] [<c010ad3f>] kernel_
[95952.972383] ---[ end trace 23f4d7031cac367e ]---
[95953.018537] r8169: eth0: link up
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
OXullo Intersecans (oxullo) wrote : | #10 |
Same here, but with a slight variant.
* Hardware
- Gigabyte GA-EX58-UD3R (rev. 1.6), CPU: Core i7 - 920, RAM: 3x Corsair TR3X6G1600C9
- Onboard ethernet controller: Realtek 8111C
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Subsystem: Giga-byte Technology Device e000
Flags: bus master, fast devsel, latency 0, IRQ 2294
I/O ports at 7e00 [size=256]
Memory at fd6ff000 (64-bit, prefetchable) [size=4K]
Memory at fd6f8000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at fd600000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
Connected to a Zyxel gigabit switch.
* OS
- Ubuntu Jaunty 9.04
* Scenario 1:
- Linux mtt-r3 2.6.28-3-rt #12-Ubuntu SMP PREEMPT RT Fri Apr 17 10:09:11 UTC 2009 i686 GNU/Linux
- Stock r8169 driver
I got a crash pretty soon (over 6 retries, I had a mean time of 3 to 8 minutes, even with small amount of transfers), with the following log report:
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982385] ------------[ cut here ]------------
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982387] WARNING: at /build/
watchdog+
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982389] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982390] Modules linked in: binfmt_misc ppdev bridge stp bnep video output input_po
lldev lp parport snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi raw1
394 snd_seq_midi_event video1394 snd_seq snd_timer snd_seq_device psmouse serio_raw pcspkr iTCO_wdt iTCO_vendor_support
snd soundcore joydev snd_page_alloc nvidia(P) agpgart hid_cherry usbhid ohci1394 ieee1394 r8169 mii fbcon tileblit font
bitblit softcursor
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982412] Pid: 85, comm: sirq-timer/6 Tainted: P W 2.6.28-3-rt #12-Ubuntu
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982414] Call Trace:
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982418] [<c013bde0>] warn_slowpath+
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982421] [<c02cde95>] ? __next_
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982423] [<c0131c9d>] ? find_busiest_
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982426] [<c0129967>] ? enqueue_
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982428] [<c02d309d>] ? strlcpy+0x1d/0x60
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982...
pipe (pipatron) wrote : | #11 |
I have the same problem on a Gigabyte EP35-DS3 and also an ASUS P5QL-EM motherboard with integrated RTL8111/8168B NIC. I found something interesting on this page: http://
"FYI, this bug has been around for a long time now. I've seen the same thing
happening as far back as 2.6.15, on mips based platforms. I don't have the
hardware now, but I remember that link autoneg failed randomly on r8169 and
always on the first boot. I couldn't find any fix for it, and it was generally
accepted to be a h/w bug in RTL8169.
Gregor, is it possible to use ethtool on the affected system? If this is the
same bug, forcing any mode with ethtool (100M Full/ 10M Half etc) should fail
at first, showinf 10M Half mode, and then automagically the link comes up and
there's no problem till next boot. This used to work every time on mips, for
reasons unknown."
KJ100 (k-c-jackson) wrote : | #12 |
In an earlier post OXullo indicated that the issue might be resolved with the latest kernel but I'm still seeing the issue with kernel 2.6.28-13-server #45 on a D945GCLF2 / Atom 330 mainboard.
Testing with earlier kernals showed that putting a 100Mb/s switch in front of the server helped but did not resolve the issue.
kernel: [182129.000029] ------------[ cut here ]------------
kernel: [182129.000038] WARNING: at /build/
kernel: [182129.000044] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
kernel: [182129.000048] Modules linked in: video output input_polldev lp snd_hda_intel iTCO_wdt iTCO_vendor_support snd_pcm snd_timer ppdev psmouse snd intel_agp serio_raw soundcore pcspkr agpgart parport_pc parport snd_page_alloc r8169 mii fbcon tileblit font bitblit softcursor
kernel: [182129.000096] Pid: 0, comm: swapper Not tainted 2.6.28-13-server #45-Ubuntu
kernel: [182129.000101] Call Trace:
kernel: [182129.000111] [<c01411d0>] warn_slowpath+
kernel: [182129.000120] [<c0133e6c>] ? enqueue_
kernel: [182129.000128] [<c0139891>] ? enqueue_
kernel: [182129.000134] [<c012ff17>] ? enqueue_
kernel: [182129.000141] [<c013b2cc>] ? try_to_
kernel: [182129.000149] [<c02d39ad>] ? strlcpy+0x1d/0x60
avahi-
last message repeated 2 times
kernel: [182129.000156] [<c043b762>] ? netdev_
kernel: [182129.000163] [<c044fdc9>] dev_watchdog+
kernel: [182129.000170] [<c0153321>] ? __queue_
kernel: [182129.000178] [<c014b6d0>] run_timer_
kernel: [182129.000184] [<c044fbb0>] ? dev_watchdog+
kernel: [182129.000190] [<c044fbb0>] ? dev_watchdog+
kernel: [182129.000198] [<c01467d7>] __do_softirq+
kernel: [182129.000204] [<c015a896>] ? hrtimer_
kernel: [182129.000211] [<c015a6e9>] ? ktime_get+0x19/0x40
kernel: [182129.000217] [<c014690d>] do_softirq+
kernel: [182129.000224] [<c0146a85>] irq_exit+0x55/0x90
kernel: [182129.000230] [<c011f8fb>] smp_apic_
kernel: [182129.000238] [<c010ac2c>] apic_timer_
kernel: [182129.000245] [<c0110a12>] ? mwait_idle+
kernel: [182129.000252] [<c010884d>] cpu_idle+0x6d/0xd0
kernel: [182129.000259] [<c04f9fbe>] rest_init+0x4e/0x60
kernel: [182129.000264] ---[ end trace 2a54a0b35234228f ]---
kernel: [182129.041138] r8169: eth0: link up
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
...
Tommy Vestermark (tov) wrote : | #13 |
I can confirm this bug on a D945GCLF2 / Atom 330 board when running kernel 2.6.28-13-generic. It occurs within a few minutes when running heavy network traffic (NFS server).
I have now upgraded the kernel to 2.6.30-10-generic (from Karmic), and have been running for 10 days without any issue at all! It seems like the issue is solved in the newer kernels, so please try a 2.6.30 kernel and report whether the issue can be reproduced.
Ethan Apodaca (papodaca) wrote : | #14 |
I have the D945GCLF2D Atom 330 board, heavy traffic triggers a dead network (2.6.28-
Leann Ogasawara (leannogasawara) wrote : | #15 |
Tommy's comment sounds promising - https:/
Changed in linux (Ubuntu): | |
status: | Confirmed → Incomplete |
sulnam (sealsul) wrote : | #16 |
I got exactly same problem.
Is that everything OK with kernel 2.6.30 really?
My ethernet card status is like below
And I found the latest driver of RTL8111 driver , it was released 5th May 2009.
I didn't install it yet.
But I prefer to modify kernel instead of setting driver manually.
-------
*-network
bus info: pci@0000:01:00.0
Andreas Kern (kerna) wrote : | #17 |
Switched to mainline kernel, my problem didn't accour since that. (driver crashes on heavy load)
today looked at the new ubuntu kernel update (2.6.28-14)
* r8169: fix crash when large packets are received
http://
maybe this is related, so it should be fixed in the normal ubuntu kernel, don't have time to test it right now.
Toby Corkindale (tjc-wintrmute) wrote : | #18 |
I have tested with 2.6.28-14 and the problem occurs still. Easily. :(
Nicolas Picard (true255) wrote : | #19 |
Same thing when I'm using kernel 2.6.28-15.
basdoorn (bas2009) wrote : | #20 |
- syslog details Edit (2.9 KiB, text/plain)
Confirmed on Ubuntu 9.04 (Jaunty), running 2.6.28-14-generic, tried kernel noapic option but that did not help. I am running an Intel D945GSEJT Mini-ITX board with Intel Atom N270 and Realtek Gigabit controller, lspci lists it as
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
This machine functions as a Samba filesharing server. When a user tries to copy large files from the server to their workstation the 'transmit timed out' message typically appears after 1.5-2GB or so, after which the client machine reports the file share is no longer available. It does come back automatically after about 5-20 seconds but file copying runs into the same issue even after this. The network is completely down when this happens, even SSH connections fail during this period.
Leann Ogasawara (leannogasawara) wrote : | #21 |
@Jorge Suarez, since you are the original bug reporter, can you test the latest Karmic 9.10 Alpha release which contains a 2.6.31 based kernel. I'd like to hear your results. Thanks.
Ben (bronkb) wrote : | #22 |
I had been having this problem too w/ an Asus M3A78-EMH (780G) motherboard ever since the switch from Intrepid to Janunty. I switched to 2.6.31-999-generic #200908211846 from the mainline kernel repository (https:/
basdoorn (bas2009) wrote : | #23 |
In addition to my last report I had a network failure even after having forced the Realtek lan interface to 100MBit. The link failed after about 7GB of data transfer of a single large file. I have switched to an old PCI card, a 3Com 3C905B, which is working fine until now. I have now transferred a single 50GB archive succesfully, something which has not been possible in Jaunty so far with this mainboards NIC.
Brandon Rhodes (brandon-rhodes) wrote : | #24 |
I have tried what looks like the most recent kernel being prepared for Kosmic Koala (9.10), and my Ethernet controller was no more stable than before; it will, after being plugged in, toss a few pings back and forth with an 80% packet loss, then give up altogether. Its "lspci" entry is:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
The kernels I tried upgrading my Jaunty Jackelope (9.04) server to (by downloading them directly from the Ubuntu package repository then installing them via "dpkg -i") were (copying the following from my dpkg.log file to make sure I don't make a mistake):
linux-image-
rc8 2.6.31-020631rc8
linux-image-
Brandon Rhodes (brandon-rhodes) wrote : | #25 |
Oh: and, the "mainline builds" wouldn't even boot for me because I use LVM over RAID which confused them and caused them to halt (with some sort of error about the RAID housing an unrecognized kind of partition). So I can't say whether they would have worked with my Ethernet card or not.
roemer2201 (roemer2201) wrote : | #26 |
I got the same problems on Mainboard/
Can anyone confirm that an update to koala alpha/beta helps solving the problem?
=======
[ 12.924553] r8169: eth0: link up
[ 12.924569] r8169: eth0: link up
[ 22.380530] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 22.380536] Bluetooth: BNEP filters: protocol multicast
[ 22.413915] Bridge firewalling registered
[ 23.711284] eth0: no IPv6 routers present
[ 24.869879] [drm] Initialized drm 1.1.0 20060810
[ 24.961001] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 24.961016] pci 0000:00:02.0: setting latency timer to 64
[ 24.961535] [drm] Initialized i915 1.6.0 20080730 on minor 0
[ 27.815648] eth1: link down
[ 27.816225] ADDRCONF(
[ 606.970032] ------------[ cut here ]------------
[ 606.970041] WARNING: at /build/
[ 606.970047] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[ 606.970051] Modules linked in: i915 drm binfmt_misc bridge stp bnep input_polldev video output smsc47m1 smsc47m192 hwmon_vid i2c_i801 lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device iTCO_wdt iTCO_vendor_support snd ppdev psmouse intel_agp soundcore pcspkr serio_raw agpgart snd_page_alloc parport_pc parport usb_storage 8139too 8139cp r8169 mii fbcon tileblit font bitblit softcursor
[ 606.970131] Pid: 0, comm: swapper Not tainted 2.6.28-15-server #51-Ubuntu
[ 606.970135] Call Trace:
[ 606.970145] [<c01412e0>] warn_slowpath+
[ 606.970155] [<c02c0030>] ? __generic_
[ 606.970163] [<c0138b3d>] ? find_busiest_
[ 606.970170] [<c013ab68>] ? balance_
[ 606.970179] [<c015e683>] ? getnstimeofday+
[ 606.970187] [<c02d410d>] ? strlcpy+0x1d/0x60
[ 606.970196] [<c043c5c2>] ? netdev_
[ 606.970203] [<c0450ca9>] dev_watchdog+
[ 606.970209] [<c015e683>] ? getnstimeofday+
[ 606.970217] [<c011f2f3>] ? lapic_next_
[ 606.970224] [<c01618a8>] ? clockevents_
[ 606.970232] [<c014b830>] run_timer_
[ 606.970238] [<c0450a90>] ? dev_watchdog+
[ 606.970245] [<c0450a90>] ? dev_watchdog+
[ 606.970253] [<c01468f7>] __do_softirq+
[ 606.970259] [<c015a9d6>] ? hrtimer_
[ 606.970265] [<c015a829>] ? ktime_get+0x19/0x40
[ 606.970272] [<c0146a2d>] do_softirq+
[ 606.970278] [<c0146ba5>] irq_exit+0x55/0x90
[ 606.970284] [<c011f8fb>] smp_apic_
[ 606.970292] [<c010ac2c>] apic_timer_
[ 606.970300] [<c0110a12>] ? mwait_idle+
[ 606.970307] [<c010884d>] cpu_idle+0x6d/0xd0
[ 606.970314] [<c05091fe>] start_secondary
[ 606.970320] ---[ end trace 0ca83d030425275e ]---
[ 607.011677] r8169: eth0: link up
=======
Jon Cage (jon-digital-explosion) wrote : | #27 |
Same hardware, 2.6.28-15-server, same problem.
I'm going to try the latest version [http://
Jon Cage (jon-digital-explosion) wrote : | #28 |
I just upgraded to 2.6.31-
amspilot (amspilot01) wrote : | #29 |
i am running kernel 2.6.28.15 on a gigabyte mainboard with two Realtek Ethernet 8111D chip sets.
On a all Gigabit Ethernet network. (it seems there are no problems on a 100Mb network)
config: Gigabyte GA-EX58-UD5 , CPU: Core i7 - 950, RAM: 6x2GB Corsair dominator TR3X6G1600C8D
Onboard Ethernet controller: Realtek 8111D , 4x1TB in raid10 configuration
A am experiencing disconnects when reviving large amounts data form a other network hosts.
After about 45 seconds of heavy load (smb copy of about 224Mbit/s) my NIC also stops working for one minute.
If i do a continuous ping form this system it's stops whit the messages “Ping : Sendmsg : No buffer space available”
but the nic only returns after the ping has stopped. ( is this a clue for somebody ?)
If the NIC returns after the first failure and the network load resumes the NIC almost direct stops working again. Adding extra sessions to the NIC seems to expedite the situation making the time till this failure occurs even shorter.
Does everybody have a solution for this bug. I heard that that complying the driver form the realtek webside solved the problem?
Is this the solution for this bug? Is it going to be included in the new kernels?
I need this bug fixed before I can put this machine in production and team the nic's together and add 802.1q support.
i included the output of my machine below..
-.-.-.-.-.-.-
Output :
uname -a
Linux btrbl 2.6.28-15-server #49-Ubuntu SMP Tue Aug 18 20:09:37 UTC 2009 x86_64 GNU/Linux
tail /var/log/messages | less
Sep 13 14:56:23 btrbl kernel: [ 18.624537] r8169: eth0: link up
Sep 13 14:56:23 btrbl kernel: [ 18.624542] r8169: eth0: link up
Sep 13 14:56:29 btrbl kernel: [ 25.116398] JBD: barrier-based sync failed on md0p1:8 - disabling barriers
Sep 13 15:00:35 btrbl kernel: [ 270.920010] ------------[ cut here ]------------
Sep 13 15:00:35 btrbl kernel: [ 270.920013] WARNING: at /build/
Sep 13 15:00:35 btrbl kernel: [ 270.920016] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Sep 13 15:00:35 btrbl kernel: [ 270.920017] Modules linked in: video output input_polldev lp parport snd_hda_intel iTCO_wdt snd_pcm pcspkr iTCO_vendor_support snd_timer snd soundcore snd_page_alloc usb_storage r8169 mii usbhid raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear fbcon tileblit font bitblit softcursor
Sep 13 15:00:35 btrbl kernel: [ 270.920040] Pid: 0, comm: swapper Not tainted 2.6.28-15-server #49-Ubuntu
Sep 13 15:00:35 btrbl kernel: [ 270.920042] Call Trace:
Sep 13 15:00:35 btrbl kernel: [ 270.920044] <IRQ> [<ffffffff80250
Sep 13 15:00:35 btrbl kernel: [ 270.920053] [<ffffffff805a5
Sep 13 15:00:35 btrbl kernel: [ 270.920057] [<ffffffff80417
Sep 13 15:00:35 btrbl kernel: [ 270.920059] [<ffffffff80417
Sep 13 15:00:35 btrbl kernel: [ 270.920064] [<ffffffff80242
Sep 13 15:00:35 btrbl kernel: [ 270.920067] [<ffffffff80248
Sep 13 15:00:35...
amspilot (amspilot01) wrote : | #30 |
update : NETDEV WATCHDOG gone after driver update form 2009/8/31 Realtek , but still Disconnects occur and the interface is now flapping up/down. in kernel 2.6.28-15-server
the system: Gigabyte GA-EX58-UD5 , CPU: Core i7 - 950, RAM: 6x2GB Corsair TR3X6G1600C8D
Onboard two Ethernet controller: Realtek 8111D , 4x1TB in raid10 configuration
So the rumors persisted that the realtek driver could solve the problem: ( Sorry it's better but the disconnections are still there )
This is what I did and the results :
: I download the new realtek linux driver from the webside :
from: : http://
name / version / Update time / file size
LINUX driver for kernel 2.6.x and 2.4.x (Support x86 and x64) / 8.014.00 / 2009/8/31 / 40KB
I installed the build-essential and the linux-headres-
# apt-get install build-essential
# apt-get install linux-headers
I flowed the instructions that came whit the driver now to the letter, see 'realtek driver instructions'
Begin the transfer testing of small and large files about 24.000 small files and about 1.000 lage files. Just for loading the system.
I used three systems to load the server, two with samba smb and one ssh session, but still the local io restrictions of the workstations prevent me form max loading the server.
(I want to use real systems and io and not iperf to load the system for now)
The system performed well for about 30Min during heavy load of about 330Mbit/sec on average. Then a disconnect occurred for about 4 minutes after that the system recovered for a wile.
It's better but the system is still not stable !!!. / system is not production ready until this problem is solved or a work around is found .!!
the “NETDEV WATCHDOG” messages are gone but “r8168: eth0 : link up” and “r8168: eth0: link down” messages have appeared.
Additional information
lspci -vvv
ethtool eth0
The following messages were included after the installation
ifconfig eth0
realtek driver update procedure
-.-.-.-
lspci -vvv
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Subsystem: Giga-byte Technology Device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 2293
Region 0: I/O ports at ae00 [size=256]
Region 2: Memory at fbaff000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at fbaf8000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at fba00000 [disabled] [size=128K]
...
paul hoenecke (pmh009) wrote : | #31 |
2.6.28.15-generic kernel on Intel D945GCLF2 (realtek 8111c , driver r8169). Completely fresh install.
When accessing SMB share from Windows PC, transfers to the Ubuntu machine seem to work fine. Any medium to large file transfer TO the ubuntu machine from the Windows PC will fail. Exact same "Transmit timed out" message as stated above.
basdoorn (bas2009) wrote : | #32 |
Installed the 2.6.30 mainline kernel and have not had issues so far, tried a single 9GB filetransfer which ran at about 60MB/s average. Did this both from and to the server using SMB. Jaunty did not boot properly with the 2.6.31 kernel on my board, so I could not test it as well, probably due to the videocard driver conflicting with the new kernel which requires the new intel driver model. The 2.6.28-15 kernel still has this issue, confirmed with all Jaunty updates up until today installed.
I am running an Intel D945GSEJT Mini-ITX board with Intel Atom N270 and Realtek Gigabit controller, lspci lists it as
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Laurent Bonnaud (laurent-bonnaud) wrote : | #33 |
I do not see this problem any longer with karmic and the 2.6.31 kernel.
Nicolas Picard (true255) wrote : | #34 |
I guest that we have to wait for Karmic release.... and it comming out almost at October's end. Can't longer wait to get that annoying bug fixed.
William King (quentusrex) wrote : | #35 |
- therabbit.txt Edit (22.0 KiB, text/plain)
I have the bug too with a Gigabyte P55-UD4P motherboard. I almost RMA'd the board because I thought it was a bad board.
My symptoms: I have freeswitch(open source voip software) calling into a 16khz conference call, so about 90Kbps constant for the whole afternoon, with an ssh session open with screen(the dark profile so I can see the clock in the bottom right). I'm using Jaunty 9.04 server, with an Intel i7 860 processor with 8GB of RAM. I've called this machine 'therabbit'.
Basically, all audio in and out from the voip call, and all data in the ssh connection stop. This happens every 30 minutes or so. Then after 4-5 minutes all the connections continue. None of the connections have dropped, but no audio or ssh data is passed in the 'blackout period'.
I will upgrade to Karmic when it comes out on Saturday.
Nicolas Picard (true255) wrote : | #36 |
Well, as expected, I upgraded from Jaunty to Karmic and that annoying problem is now gone. Data transferts no longer stop and time out. I'm using Intel D945GCLF2 board. So... is it fine on yours side ? I thinks that we can close that bug now.
uscallesen (uffe-callesen) wrote : | #37 |
I have no issues after upgrading to Karmic.
amspilot (amspilot01) wrote : Re: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty | #38 |
Hi Nicolas,
Sorry to say, but i have not had the time to do an update as just jet, so i can not denny or confirm that the problem is solved in u9.10.
but i am sertanly going to do this a lot sooner now jou have reported that the problem was solved.
thanks for you feedback,
best Regards,
Dave.
De inhoud van dit e-mailbericht en van de eventueel meegezonden bestanden is strikt vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Gebruik van deze inhoud door anderen zonder toestemming van de afzender of de geadresseerde is onrechtmatig.
This message and any other enclosed documents are strictly confidential and intended for the addressee only. Any use by others without the consent of the sender or the addressee is unlawful.
--- On Sun, 11/1/09, Nicolas Picard <email address hidden> wrote:
> From: Nicolas Picard <email address hidden>
> Subject: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty
> To: <email address hidden>
> Date: Sunday, November 1, 2009, 6:32 AM
> Well, as expected, I upgraded from
> Jaunty to Karmic and that annoying
> problem is now gone. Data transferts no longer stop and
> time out. I'm
> using Intel D945GCLF2 board. So... is it fine on yours side
> ? I thinks
> that we can close that bug now.
>
> --
> Realtek RTL8111/8168B PCI Express Gigabit Ethernet
> controller Unstable on Jaunty
> https:/
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>
> Status in The Linux Kernel: Incomplete
> Status in “linux” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: linux-image-
>
> Related to this bug:
>
> http://
>
> andres@
> Description: Ubuntu jaunty (development
> branch)
> Release: 9.04
>
> Mainboard/
>
> Network unstable on the latest kernel, worked fine on
> Intrepid Ibex.
> Network goes down even though mii-tool still says
> negotiated, appears to be related to the network
> driver/adapter which is:
>
> 01:00.0 Ethernet controller: Realtek Semiconductor Co.,
> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
> (rev 02)
>
> Dmesg output
>
> [ 284.816023] ------------[ cut here ]------------
> [ 284.816032] WARNING: at
> /build/
> dev_watchdog+
> [ 284.816038] NETDEV WATCHDOG: eth2 (r8169): transmit
> timed out
> [ 284.816042] Modules linked in: binfmt_misc i915 drm
> bridge stp bnep video output input_polldev smsc47m1
> smsc47m192 hwmon_vid i2c_i801 sbp2 ieee1394 lp snd_hda_intel
> snd_pcm_oss snd_mixer_oss snd_pcm ppdev snd_seq_dummy
> snd_seq_oss snd_seq_midi iTCO_wdt iTCO_vendor_support
> snd_rawmidi psmouse pcspkr snd_seq_midi_event serio_raw
> snd_seq snd_timer snd_seq_device parport_pc parport snd
> intel_agp soundcore snd_page_alloc agpgart usbhid
> usb_storage r8169 mii fbcon tileblit font bitblit
> softcursor
> [ 284.816119] Pid: 4, comm: ksoftirqd/0 Not tainted
> 2.6.28-11-generic #37-Ubuntu
> [ 284.816123] Call Trace:
> [ 284.816135] [<c0139a60>]
> w...
William King (quentusrex) wrote : Re: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty | #39 |
I can confirm that it is fixed in 9.10.
On Sun, Nov 1, 2009 at 2:02 PM, amspilot <email address hidden> wrote:
> Hi Nicolas,
>
> Sorry to say, but i have not had the time to do an update as just jet,
> so i can not denny or confirm that the problem is solved in u9.10.
>
> but i am sertanly going to do this a lot sooner now jou have reported
> that the problem was solved.
>
> thanks for you feedback,
>
> best Regards,
>
> Dave.
>
> De inhoud van dit e-mailbericht en van de eventueel meegezonden
> bestanden is strikt vertrouwelijk en uitsluitend bestemd voor de
> geadresseerde. Gebruik van deze inhoud door anderen zonder toestemming
> van de afzender of de geadresseerde is onrechtmatig.
>
> This message and any other enclosed documents are strictly confidential
> and intended for the addressee only. Any use by others without the
> consent of the sender or the addressee is unlawful.
>
>
> --- On Sun, 11/1/09, Nicolas Picard <email address hidden> wrote:
>
>> From: Nicolas Picard <email address hidden>
>> Subject: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty
>> To: <email address hidden>
>> Date: Sunday, November 1, 2009, 6:32 AM
>> Well, as expected, I upgraded from
>> Jaunty to Karmic and that annoying
>> problem is now gone. Data transferts no longer stop and
>> time out. I'm
>> using Intel D945GCLF2 board. So... is it fine on yours side
>> ? I thinks
>> that we can close that bug now.
>>
>> --
>> Realtek RTL8111/8168B PCI Express Gigabit Ethernet
>> controller Unstable on Jaunty
>> https:/
>> You received this bug notification because you are a direct
>> subscriber
>> of the bug.
>>
>> Status in The Linux Kernel: Incomplete
>> Status in “linux” package in Ubuntu: Incomplete
>>
>> Bug description:
>> Binary package hint: linux-image-
>>
>> Related to this bug:
>>
>> http://
>>
>> andres@
>> Description: Ubuntu jaunty (development
>> branch)
>> Release: 9.04
>>
>> Mainboard/
>>
>> Network unstable on the latest kernel, worked fine on
>> Intrepid Ibex.
>> Network goes down even though mii-tool still says
>> negotiated, appears to be related to the network
>> driver/adapter which is:
>>
>> 01:00.0 Ethernet controller: Realtek Semiconductor Co.,
>> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
>> (rev 02)
>>
>> Dmesg output
>>
>> [ 284.816023] ------------[ cut here ]------------
>> [ 284.816032] WARNING: at
>> /build/
>> dev_watchdog+
>> [ 284.816038] NETDEV WATCHDOG: eth2 (r8169): transmit
>> timed out
>> [ 284.816042] Modules linked in: binfmt_misc i915 drm
>> bridge stp bnep video output input_polldev smsc47m1
>> smsc47m192 hwmon_vid i2c_i801 sbp2 ieee1394 lp snd_hda_intel
>> snd_pcm_oss snd_mixer_oss snd_pcm ppdev snd_seq_dummy
>> snd_seq_oss snd_seq_midi iTCO_wdt iTCO_vendor_support
>> snd_rawmidi psmouse pcspkr snd_seq_midi_event serio_raw
>> snd_seq snd_timer snd_seq_device parport_pc parport snd
>> intel_agp soundcore snd_page_alloc agpgart usbhid
>> usb_stor...
Jon Cage (jon-digital-explosion) wrote : Re: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express GigabitEthernet controller Unstable on Jaunty | #40 |
I can cnofirm that the latest update (using kernel 2.6.31-14-generic)
appears to have fixed the problem.
On Sun, 01 Nov 2009 22:25:11 -0000, William King <email address hidden>
wrote:
> I can confirm that it is fixed in 9.10.
>
> On Sun, Nov 1, 2009 at 2:02 PM, amspilot <email address hidden> wrote:
>> Hi Nicolas,
>>
>> Sorry to say, but i have not had the time to do an update as just jet,
>> so i can not denny or confirm that the problem is solved in u9.10.
>>
>> but i am sertanly going to do this a lot sooner now jou have reported
>> that the problem was solved.
>>
>> thanks for you feedback,
>>
>> best Regards,
>>
>> Dave.
>>
>> De inhoud van dit e-mailbericht en van de eventueel meegezonden
>> bestanden is strikt vertrouwelijk en uitsluitend bestemd voor de
>> geadresseerde. Gebruik van deze inhoud door anderen zonder toestemming
>> van de afzender of de geadresseerde is onrechtmatig.
>>
>> This message and any other enclosed documents are strictly confidential
>> and intended for the addressee only. Any use by others without the
>> consent of the sender or the addressee is unlawful.
>>
>>
>> --- On Sun, 11/1/09, Nicolas Picard <email address hidden> wrote:
>>
>>> From: Nicolas Picard <email address hidden>
>>> Subject: [Bug 347711] Re: Realtek RTL8111/8168B PCI Express Gigabit
> Ethernet controller Unstable on Jaunty
>>> To: <email address hidden>
>>> Date: Sunday, November 1, 2009, 6:32 AM
>>> Well, as expected, I upgraded from
>>> Jaunty to Karmic and that annoying
>>> problem is now gone. Data transferts no longer stop and
>>> time out. I'm
>>> using Intel D945GCLF2 board. So... is it fine on yours side
>>> ? I thinks
>>> that we can close that bug now.
>>>
>>> --
>>> Realtek RTL8111/8168B PCI Express Gigabit Ethernet
>>> controller Unstable on Jaunty
>>> https:/
>>> You received this bug notification because you are a direct
>>> subscriber
>>> of the bug.
>>>
>>> Status in The Linux Kernel: Incomplete
>>> Status in “linux” package in Ubuntu: Incomplete
>>>
>>> Bug description:
>>> Binary package hint: linux-image-
>>>
>>> Related to this bug:
>>>
>>> http://
>>>
>>> andres@
>>> Description: Ubuntu jaunty (development
>>> branch)
>>> Release: 9.04
>>>
>>> Mainboard/
>>>
>>> Network unstable on the latest kernel, worked fine on
>>> Intrepid Ibex.
>>> Network goes down even though mii-tool still says
>>> negotiated, appears to be related to the network
>>> driver/adapter which is:
>>>
>>> 01:00.0 Ethernet controller: Realtek Semiconductor Co.,
>>> Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
>>> (rev 02)
>>>
>>> Dmesg output
>>>
>>> [ 284.816023] ------------[ cut here ]------------
>>> [ 284.816032] WARNING: at
>>> /build/
>>> dev_watchdog+
>>> [ 284.816038] NETDEV WATCHDOG: eth2 (r8169): transmit
>>> timed out
>>> [ 284.816042] Modules linked in: binfmt_misc i915 drm
>>> bridge stp bnep video output input_polldev smsc47m1
>>> smsc47m192 hwmon_vid i2c_i801 sbp2 ieee1394 lp snd_hda_intel
>>> snd_pcm_oss sn...
Raph (raph-redsonic) wrote : | #41 |
Hi, I've same problem with kernel 2.6.31-14!
[ 11.633891] r8169: eth0: link down
[ 11.634259] ADDRCONF(
*-network
description: Ethernet interface
product: RTL8111/8168B PCI Express Gigabit Ethernet controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth0
version: 01
serial: 00:1c:c0:fd:69:7d
size: 100MB/s
capacity: 1GB/s
width: 64 bits
clock: 33MHz
resources: irq:27 ioport:
sascha (sascha-siebenlinden) wrote : | #42 |
Definitely not fixed in 9.01.
I made a fresh karmik-install (2.6.31-15) (Board: D945GCLF2).
The wrong r8169 - driver is still used.
Even in 100Mbit-Mode, high network traffic causes dropouts for a minute.
Seeing this heavy BUG not fixed let me seriously doubt about Ubuntu beeing a
recommendable Server-System.
Cheers,
Sascha
Changed in linux: | |
status: | Incomplete → In Progress |
Chafik Hankour (chankour) wrote : | #43 |
Same problem here with Kernel 2.6.31-
DaveR (daver-derdev) wrote : | #44 |
Same problem with Zotac ION ITX Atom 230 mb Ubuntu 9.10 but not Realtek controller
Kernel 2.6.31-19-generic #56-Ubuntu
lspci -vvv
00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
Subsystem: ZOTAC International (MCO) Ltd. Device a108
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at fae7c000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d080 [size=8]
Region 2: Memory at fae7e400 (32-bit, non-prefetchable) [size=256]
Region 3: Memory at fae7e000 (32-bit, non-prefetchable) [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
Kernel driver in use: forcedeth
Kernel modules: forcedeth
herrht (herrht) wrote : | #45 |
And the same was here (lag and stopped networking, while moving large amount of data), but I changed my realtek module to r8168, and since then, a didn't have any problems.
Mythubuntu 9.04, 2.6.28-15-generic.
William King (quentusrex) wrote : | #46 |
Still a problem. I haven't found the work around yet.
Mar 21 02:22:19 torrents kernel: [ 3082.885900] swapper: page allocation failure. order:0, mode:0x20
Mar 21 02:22:19 torrents kernel: [ 3082.885907] Pid: 0, comm: swapper Not tainted 2.6.31-20-server #58-Ubuntu
Mar 21 02:22:19 torrents kernel: [ 3082.885911] Call Trace:
Mar 21 02:22:19 torrents kernel: [ 3082.885914] <IRQ> [<ffffffff810e0
Mar 21 02:22:19 torrents kernel: [ 3082.885930] [<ffffffff810e0
Mar 21 02:22:19 torrents kernel: [ 3082.885947] [<ffffffff8110c
Mar 21 02:22:19 torrents kernel: [ 3082.885967] [<ffffffffa0026
Mar 21 02:22:19 torrents kernel: [ 3082.885974] [<ffffffffa0027
Mar 21 02:22:19 torrents kernel: [ 3082.885982] [<ffffffff8143b
Mar 21 02:22:19 torrents kernel: [ 3082.886064] [<ffffffffa0026
Mar 21 02:22:19 torrents kernel: [ 3082.886072] [<ffffffff81065
Mar 21 02:22:19 torrents kernel: [ 3082.886078] [<ffffffff81013
Mar 21 02:22:19 torrents kernel: [ 3082.886083] [<ffffffff81014
Mar 21 02:22:19 torrents kernel: [ 3082.886088] [<ffffffff81064
Mar 21 02:22:19 torrents kernel: [ 3082.886092] [<ffffffff81014
Mar 21 02:22:19 torrents kernel: [ 3082.886104] [<ffffffff81012
Mar 21 02:22:19 torrents kernel: [ 3082.886107] <EOI> [<ffffffff81035
Mar 21 02:22:19 torrents kernel: [ 3082.886127] [<ffffffff8101a
Mar 21 02:22:19 torrents kernel: [ 3082.886149] [<ffffffff8152c
Mar 21 02:22:19 torrents kernel: [ 3082.886155] [<ffffffff81010
Mar 21 02:22:19 torrents kernel: [ 3082.886164] [<ffffffff81515
Mar 21 02:22:19 torrents kernel: [ 3082.886202] [<ffffffff8183c
Mar 21 02:22:19 torrents kernel: [ 3082.886280] [<ffffffff8183b
Mar 21 02:22:19 torrents kernel: [ 3082.886286] [<ffffffff8183b
Mar 21 02:22:19 torrents kernel: [ 3082.886290] Mem-Info:
Mar 21 02:22:19 torrents kernel: [ 3082.886293] Node 0 DMA per-cpu:
Mar 21 02:22:19 torrents kernel: [ 3082.886297] CPU 0: hi: 0, btch: 1 usd: 0
Mar 21 02:22:19 torrents kernel: [ 3082.886300] Node 0 DMA32 per-cpu:
Mar 21 02:22:19 torrents kernel: [ 3082.886304] CPU 0: hi: 186, btch: 31 usd: 184
Mar 21 02:22:19 torrents kernel: [ 3082.886378] Active_anon:1160 active_file:102850 inactive_anon:1241
Mar 21 02:22:19 torrents kernel: [ 3082.886380] inactive_
Mar 21 02:22:19 torrents kernel: [ 3082.886382] free:1367 slab:4601 mapped:19129 pagetables:1046 bounce:0
Mar 21 02:22:19 torrents kernel: [ 3082.886386] Node 0 DMA free:3992kB min:60kB low:7...
William King (quentusrex) wrote : | #47 |
Problem appears back in Linux therabbit 2.6.31-20-server #58-Ubuntu SMP Fri Mar 12 05:40:05 UTC 2010 x86_64 GNU/Linux
William King (quentusrex) wrote : | #48 |
I'm using http://
dancelover (dancelover) wrote : | #49 |
I can confirm this bug on a D945GCLF2 board when running Jaunty server. It occurs when running heavy network traffic
# lspci -vvv
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: Intel Corporation Device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 2300
Region 0: I/O ports at 1000 [size=256]
Region 2: Memory at 28100000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at 28000000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 28020000 [disabled] [size=128K]
Kernel driver in use: r8169
Kernel modules: r8168, r8169
Solved compiling r8168 module from realteck site
HowTo --> http://
(do make & make install as root)
Rechner-Tester (cs-rechner) wrote : | #50 |
Same problem here with lucid x86 on an asus P5B board.
lspci:
[...]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
[...]
KapteinPyn (philip-coetzee) wrote : | #51 |
Same problem with
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Daugl (d-laurent) wrote : | #52 |
I have this problem with RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
on 2.6.32-25-generic, but i remember that it worked with previous kernel.
Rechner-Tester (cs-rechner) wrote : | #53 |
I could lately "fix" this problem by deactivating the energy saving option for the corresponding LAN port in the Router/
Since I have no other operating system installed I unfortunately can not say if this is a problem with the FritzBox or if the kernel tries reducing the power consumption to aggressive
Chorca (chorca) wrote : | #54 |
Happening to me as well. 2.6.27-17 on Intrepid. D945GCLF2 board.
Timeouts at random intervals, usually while transferring data. drops out for about a minute or so.
sirio81 (sirio81) wrote : | #55 |
sirio81 (sirio81) wrote : | #56 |
I have the same problem on kubuntu 10.4.
I had similar behaviour with debian lenny (kernek 2.6.26) but not with squeeze or a bacport kernel (2.6.32).
Changed in linux: | |
status: | In Progress → Confirmed |
sirio81 (sirio81) wrote : | #57 |
sorry, also with sqeeze I have the same problem.
I hope it's not a hardware related problem.
Johan (ignesia) wrote : | #58 |
r8169 does not work properly on 2.6.32-27-generic #49-Ubuntu SMP x86_64 GNU/Linux
Drops connection constantly.
Changed in linux: | |
importance: | Unknown → Medium |
felixrising (matt-mu) wrote : | #59 |
The incorrect module is detected and loaded, unfortunately this bug has existed for around 4+ years now.
Currently does not work on Ubuntu 11.04 (GNU/Linux 2.6.38-8-server x86_64)
These are the same bug:
https:/
https:/
https:/
DanieW (dawessels) wrote : | #60 |
This is getting worse.. Now with Natty 11.04 I can not even get it to work by rebooting to Windows, disable and enable the NIC again and then reboot to Ubuntu (like with 10.10) to have a working NIC. Driver with Fedora 10 or 11 was much more stable.
lspci:03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
uname -a
Linux donderweer 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux
modinfo r8169
filename: /lib/modules/
firmware: rtl_nic/
firmware: rtl_nic/
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <email address hidden>
srcversion: B5846A288645E41
alias: pci:v00000001d0
alias: pci:v00001737d0
alias: pci:v000016ECd0
alias: pci:v00001259d0
alias: pci:v00001186d0
alias: pci:v000010ECd0
alias: pci:v000010ECd0
alias: pci:v000010ECd0
alias: pci:v000010ECd0
alias: pci:v000010ECd0
depends:
vermagic: 2.6.38-8-generic SMP mod_unload modversions 686
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
See
http://
for the Realtek option I am about to try
DanieW (dawessels) wrote : | #61 |
Yes, that RealTek driver worked nicely (.. for eth0), installation was very easy: sudo bunzip2 r8168-8.
.... but it did
Check old driver and unload it.
rmmod r8169
Build the module and install
[: 48: r8168: unexpected operator
Backup r8169.ko
rename r8169.ko to r8169.bak
Depending module. Please wait.
load module r8168
Completed.
and unfortunately I still need r8168 to work for my other NIC. (eth4)
I rename the .bak back again to .ko but modprobe r8169 says:
FATAL: Module r8169 not found.
So, I am now stuck here. (It also is not in blacklist in /etc/modprobe.d/
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix". | #62 |
This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.
Changed in linux (Ubuntu): | |
status: | Incomplete → Won't Fix |
Alain Danger (alain-danger) wrote : | #63 |
This bug is still present in Linux-2.
Changed in linux: | |
status: | Confirmed → Incomplete |
William King (quentusrex) wrote : | #64 |
After finally being able to reproduce the issue while getting a switch level pcap it turns out that under high traffic loads when the cpu idle % is low the card/driver starts to lose packets due to either the packets being overwritten or corrupted when new packets are received. The drop out is caused when a high traffic tcp connection detects a failed receive and retransmits. The retransmit occurs when the inbound network packets are already being dropped/corrupted, so a cascade effect occurs.
This effect can also be seen if you write a little C app that sends udp packets to a listening app on the server. If you have each udp packet include an incrementing counter, when the cpu idle % drops below ~50% there will be loss(in my case between 3-5% loss) and as the cpu idle reaches as low as 30% the loss rate increases(40% or higher loss, not out of order but completely lost between the NIC and the app). If you change the app to use a tcp connection for the same test the tcp retransmission rate grows roughly in line with the udp loss rate when graphed against the cpu idle percent.
When tested using an Intel NIC with an e1000e driver there is no such loss until the cpu idle drops below single digits.
Richard Hansen (rhansen) wrote : | #65 |
@William King: Please report your findings to the upstream kernel bug report.
Changed in linux: | |
status: | Incomplete → Expired |
DanieW (dawessels) wrote : | #66 |
No, why? Why report it to https:/
which now has Status: CLOSED INSUFFICIENT_DATA
d@xxxx:~$ uname -av
Linux xxxx 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012 i686 i686 i386 GNU/Linux
d@xxxx:~$ dmesg | grep eth
[ 0.170496] i2c-core: driver [aat2870] using legacy suspend method
[ 0.170498] i2c-core: driver [aat2870] using legacy resume method
[ 1.429777] r8169 0000:03:00.0: eth0: RTL8168b/8111b at 0xf800e000, 00:1c:c0:xx:xx:xx, XID 98500000 IRQ 43
[ 1.429781] r8169 0000:03:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
[ 1.431517] r8169 0000:04:06.0: eth1: RTL8169sb/8110sb at 0xf8012000, f0:7d:68:yy:yy:yy, XID 10000000 IRQ 21
[ 1.431521] r8169 0000:04:06.0: eth1: jumbo features [frames: 7152 bytes, tx checksumming: ok]
[ 12.413341] ADDRCONF(
[ 12.413348] ADDRCONF(
[ 14.568561] udevd[570]: renamed network interface eth1 to eth4
[ 101.926717] r8169 0000:03:00.0: eth0: link down
[ 101.926724] r8169 0000:03:00.0: eth0: link down
[ 101.926886] ADDRCONF(
[ 101.927170] ADDRCONF(
[ 101.930823] r8169 0000:04:06.0: eth4: link down
[ 101.930828] r8169 0000:04:06.0: eth4: link down
[ 101.930981] ADDRCONF(
[ 101.931292] ADDRCONF(
[ 104.702200] r8169 0000:04:06.0: eth4: link up
[ 104.702368] ADDRCONF(
[ 137.301220] [UFW BLOCK] IN=eth4 OUT= MAC=f0:
when I have used the driver 8168 from Realtek it has worked before (should still work) but when I use the 8169 (current)
driver it does not and I want to use both NICs.
See previous efforts at #60 above.
Kindly waiting for a response of what information anyone would require to help with this. I just have to little knowledge at the moment to fix it myself.
This is an Intrepid reinstall (it was working fine before but HDD had some errors), have the same problem, but noticed something
I don't remember having installed any special patches, but on my previous Intrepid setup my interface was named eth0, now it's named eth2. Also something weird when comparing output of mii-tool, and eththool
=> ifconfig
eth2 Link encap:Ethernet HWaddr 00:1c:c0:a7:b3:37 d58c:0: 21c:c0ff: fea7:b337/ 64 Scope:Global c0ff:fea7: b337/64 Scope:Link
collisions: 0 txqueuelen:1000
Interrupt: 220 Base address:0x2000
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2002:be9b:
inet6 addr: fe80::21c:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14671268 errors:0 dropped:0 overruns:0 frame:0
TX packets:10328468 errors:0 dropped:46 overruns:0 carrier:0
RX bytes:2911705282 (2.9 GB) TX bytes:897510370 (897.5 MB)
=> mii-tool
eth2: negotiated 1000baseT-HD flow-control, link ok
Says 1000-HD
=> ethtool eth2
100baseT/ Half 100baseT/Full
1000baseT/ Half 1000baseT/Full
100baseT/ Half 100baseT/Full
1000baseT/ Half 1000baseT/Full
Transceiver: internal
Auto-negotiati on: on
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
Says 1000FD, no way to force 1000FD on mii-tool and I don't know which is right.