Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller Unstable on Jaunty

Bug #347711 reported by Jorge Suarez on 2009-03-24
244
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Linux
Expired
Medium
linux (Ubuntu)
Undecided
Unassigned
Nominated for Jaunty by Kev Walke
Nominated for Karmic by Kev Walke
Nominated for Lucid by Kev Walke

Bug Description

Binary package hint: linux-image-2.6.28-11-generic

Related to this bug:

http://bugzilla.kernel.org/show_bug.cgi?id=12411

andres@testinserver1:~$ lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

Mainboard/Processor: D945GCLF2 / Atom 330

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/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x219/0x230()
[ 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+0x60/0x80
[ 284.816143] [<c0156873>] ? getnstimeofday+0x53/0x110
[ 284.816151] [<c0119aa3>] ? lapic_next_event+0x13/0x20
[ 284.816158] [<c0159aaa>] ? clockevents_program_event+0x9a/0x150
[ 284.816165] [<c0156873>] ? getnstimeofday+0x53/0x110
[ 284.816172] [<c02caded>] ? strlcpy+0x1d/0x60
[ 284.816180] [<c04313b2>] ? netdev_drivername+0x32/0x40
[ 284.816186] [<c0445f19>] dev_watchdog+0x219/0x230
[ 284.816193] [<c0156873>] ? getnstimeofday+0x53/0x110
[ 284.816199] [<c0119aa3>] ? lapic_next_event+0x13/0x20
[ 284.816206] [<c0159aaa>] ? clockevents_program_event+0x9a/0x150
[ 284.816214] [<c0143aa0>] run_timer_softirq+0x130/0x200
[ 284.816220] [<c0445d00>] ? dev_watchdog+0x0/0x230
[ 284.816226] [<c0445d00>] ? dev_watchdog+0x0/0x230
[ 284.816233] [<c013f147>] __do_softirq+0x97/0x170
[ 284.816240] [<c0152c36>] ? hrtimer_interrupt+0x186/0x1b0
[ 284.816246] [<c013f27d>] do_softirq+0x5d/0x60
[ 284.816253] [<c013f3f5>] irq_exit+0x55/0x90
[ 284.816259] [<c011a0ab>] smp_apic_timer_interrupt+0x5b/0x90
[ 284.816266] [<c0105318>] apic_timer_interrupt+0x28/0x30
[ 284.816274] [<c012f9ae>] ? finish_task_switch+0x2e/0xe0
[ 284.816281] [<c050106a>] schedule+0x41a/0x710
[ 284.816288] [<c013f35d>] ksoftirqd+0xdd/0x120
[ 284.816294] [<c013f280>] ? ksoftirqd+0x0/0x120
[ 284.816300] [<c014e8ac>] kthread+0x3c/0x70
[ 284.816306] [<c014e870>] ? kthread+0x0/0x70
[ 284.816312] [<c0105477>] kernel_thread_helper+0x7/0x10
[ 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 :

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
          inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: 2002:be9b:d58c:0:21c:c0ff:fea7:b337/64 Scope:Global
          inet6 addr: fe80::21c:c0ff:fea7:b337/64 Scope:Link
          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
          collisions:0 txqueuelen:1000
          RX bytes:2911705282 (2.9 GB) TX bytes:897510370 (897.5 MB)
          Interrupt:220 Base address:0x2000

=> mii-tool
eth2: negotiated 1000baseT-HD flow-control, link ok

Says 1000-HD

=> ethtool eth2
Settings for eth2:
        Supported ports: [ TP MII ]
        Supported link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        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.

nebajoth (nebajoth) wrote :

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:c0ff:fe7e:8241/64 Scope:Link
          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
          collisions:0 txqueuelen:1000
          RX bytes:111098 (111.0 KB) TX bytes:206672 (206.6 KB)
          Interrupt:252 Base address:0xa000

Refefer (refefer) wrote :

I can also confirm this is happening. Same kernel, same hardware, same result.

Andreas Kern (kerna) wrote :

i can confirm it too, also D945GCLF2

Andreas Kern (kerna) wrote :

is there a way that the watchdog reacts faster? atm it takes several minutes until the pc is reachable again

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://bugs.launchpad.net/bugs/347711
> You received this bug notification because you are a direct subscriber
> of the bug.
>

baskar (gbaskee) wrote :

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://bugs.launchpad.net/bugs/347711
> > 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://bugs.launchpad.net/bugs/347711
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Regards,
Baskaran G

Andreas Kern (kerna) wrote :

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?

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/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x219/0x230()
[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+0x60/0x80
[95952.971936] [<c0133e6c>] ? enqueue_entity+0x13c/0x360
[95952.971960] [<c0139858>] ? dequeue_task_fair+0x68/0x70
[95952.971982] [<c02ce685>] ? __next_cpu+0x15/0x30
[95952.972002] [<c0138a4d>] ? find_busiest_group+0x15d/0x7e0
[95952.972022] [<c013a31a>] ? check_preempt_wakeup+0x1aa/0x260
[95952.972041] [<c01304e3>] ? pull_task+0x43/0x60
[95952.972061] [<c013af38>] ? balance_tasks+0x88/0x110
[95952.972080] [<c02d39ad>] ? strlcpy+0x1d/0x60
[95952.972099] [<c043b762>] ? netdev_drivername+0x32/0x40
[95952.972116] [<c044fdc9>] dev_watchdog+0x219/0x230
[95952.972136] [<c013520d>] ? update_shares+0x1d/0x70
[95952.972156] [<c0139167>] ? load_balance_newidle+0x97/0x270
[95952.972178] [<c014b6d0>] run_timer_softirq+0x130/0x200
[95952.972198] [<c044fbb0>] ? dev_watchdog+0x0/0x230
[95952.972217] [<c013713b>] ? finish_task_switch+0x2b/0xe0
[95952.972238] [<c044fbb0>] ? dev_watchdog+0x0/0x230
[95952.972260] [<c01467d7>] __do_softirq+0x97/0x170
[95952.972281] [<c014690d>] do_softirq+0x5d/0x60
[95952.972300] [<c014699a>] ksoftirqd+0x8a/0x120
[95952.972317] [<c0146910>] ? ksoftirqd+0x0/0x120
[95952.972335] [<c01564dc>] kthread+0x3c/0x70
[95952.972351] [<c01564a0>] ? kthread+0x0/0x70
[95952.972369] [<c010ad3f>] kernel_thread_helper+0x7/0x10
[95952.972383] ---[ end trace 23f4d7031cac367e ]---
[95953.018537] r8169: eth0: link up

Changed in linux (Ubuntu):
status: New → Confirmed
OXullo Intersecans (oxullo) wrote :
Download full text (4.9 KiB)

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
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes: 10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    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/buildd/linux-rt-2.6.28/net/sched/sch_generic.c:227 dev_
watchdog+0x211/0x220()
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+0x60/0x80
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982421] [<c02cde95>] ? __next_cpu+0x15/0x30
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982423] [<c0131c9d>] ? find_busiest_group+0x15d/0x7f0
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982426] [<c0129967>] ? enqueue_task+0x57/0x70
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982428] [<c02d309d>] ? strlcpy+0x1d/0x60
Jul 2 16:37:01 mtt-r3 kernel: [ 8685.982...

Read more...

pipe (pipatron) wrote :

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://bugs.gentoo.org/show_bug.cgi?id=260439#c8

"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 :
Download full text (3.3 KiB)

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/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x219/0x230()
 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+0x60/0x80
 kernel: [182129.000120] [<c0133e6c>] ? enqueue_entity+0x13c/0x360
 kernel: [182129.000128] [<c0139891>] ? enqueue_task_fair+0x31/0x70
 kernel: [182129.000134] [<c012ff17>] ? enqueue_task+0x57/0x70
 kernel: [182129.000141] [<c013b2cc>] ? try_to_wake_up+0xfc/0x280
 kernel: [182129.000149] [<c02d39ad>] ? strlcpy+0x1d/0x60
 avahi-daemon[2709]: Invalid query packet.
 last message repeated 2 times
 kernel: [182129.000156] [<c043b762>] ? netdev_drivername+0x32/0x40
 kernel: [182129.000163] [<c044fdc9>] dev_watchdog+0x219/0x230
 kernel: [182129.000170] [<c0153321>] ? __queue_work+0x31/0x40
 kernel: [182129.000178] [<c014b6d0>] run_timer_softirq+0x130/0x200
 kernel: [182129.000184] [<c044fbb0>] ? dev_watchdog+0x0/0x230
 kernel: [182129.000190] [<c044fbb0>] ? dev_watchdog+0x0/0x230
 kernel: [182129.000198] [<c01467d7>] __do_softirq+0x97/0x170
 kernel: [182129.000204] [<c015a896>] ? hrtimer_interrupt+0x186/0x1b0
 kernel: [182129.000211] [<c015a6e9>] ? ktime_get+0x19/0x40
 kernel: [182129.000217] [<c014690d>] do_softirq+0x5d/0x60
 kernel: [182129.000224] [<c0146a85>] irq_exit+0x55/0x90
 kernel: [182129.000230] [<c011f8fb>] smp_apic_timer_interrupt+0x5b/0x90
 kernel: [182129.000238] [<c010ac2c>] apic_timer_interrupt+0x28/0x30
 kernel: [182129.000245] [<c0110a12>] ? mwait_idle+0x42/0x50
 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
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
       ...

Read more...

Tommy Vestermark (tov) wrote :

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 :

I have the D945GCLF2D Atom 330 board, heavy traffic triggers a dead network (2.6.28-13-generic). Compiling a alternate kernel module fixed the issue. http://ubuntuforums.org/showthread.php?t=1022411

Tommy's comment sounds promising - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/347711/comments/13 . The kernel for the upcoming Karmic release will target the 2.6.31 kernel. Can anyone else test these newer kernels and let us know your results. ISO CD images are available from http://cdimage.ubuntu.com/releases/ or alternatively you can try one of the latest Mainline kernel builds - https://wiki.ubuntu.com/KernelTeam/MainlineBuilds .

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
sulnam (sealsul) wrote :

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
                description: Ethernet interface
                product: RTL8111/8168B PCI Express Gigabit Ethernet controller
                vendor: Realtek Semiconductor Co., Ltd.
                physical id: 0
                bus info: pci@0000:01:00.0
                logical name: eth0
                version: 02
                serial: 00:1c:c0:70:fc:a5
                size: 1GB/s
                capacity: 1GB/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.0.2 latency=0 link=yes module=r8169 multicast=yes port=MII speed=1GB/s

Andreas Kern (kerna) wrote :

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://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1389

maybe this is related, so it should be fixed in the normal ubuntu kernel, don't have time to test it right now.

I have tested with 2.6.28-14 and the problem occurs still. Easily. :(

Nicolas Picard (true255) wrote :

Same thing when I'm using kernel 2.6.28-15.

basdoorn (bas2009) wrote :

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.

@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.

http://cdimage.ubuntu.com/releases/karmic/

Ben (bronkb) wrote :

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://wiki.ubuntu.com/KernelTeam/MainlineBuilds) a couple of days ago and haven't had any more problems. I've transferred at least 100gig of data so far...So if you're having this issue, make the switch, although I had to patch fglrx to get it to build correctly. https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/394985

basdoorn (bas2009) wrote :

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.

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-2.6.31-020631rc8-generic 2.6.31-020631
rc8 2.6.31-020631rc8

linux-image-2.6.31-9-386 2.6.31-9.29

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 :

I got the same problems on Mainboard/Processor: D945GCLF2 / Atom 330
Can anyone confirm that an update to koala alpha/beta helps solving the problem?

==========dmesg=============
[ 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(NETDEV_UP): eth1: link is not ready
[ 606.970032] ------------[ cut here ]------------
[ 606.970041] WARNING: at /build/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x219/0x230()
[ 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+0x60/0x80
[ 606.970155] [<c02c0030>] ? __generic_unplug_device+0x10/0x30
[ 606.970163] [<c0138b3d>] ? find_busiest_group+0x15d/0x7e0
[ 606.970170] [<c013ab68>] ? balance_tasks+0x88/0x110
[ 606.970179] [<c015e683>] ? getnstimeofday+0x53/0x110
[ 606.970187] [<c02d410d>] ? strlcpy+0x1d/0x60
[ 606.970196] [<c043c5c2>] ? netdev_drivername+0x32/0x40
[ 606.970203] [<c0450ca9>] dev_watchdog+0x219/0x230
[ 606.970209] [<c015e683>] ? getnstimeofday+0x53/0x110
[ 606.970217] [<c011f2f3>] ? lapic_next_event+0x13/0x20
[ 606.970224] [<c01618a8>] ? clockevents_program_event+0x98/0x150
[ 606.970232] [<c014b830>] run_timer_softirq+0x130/0x200
[ 606.970238] [<c0450a90>] ? dev_watchdog+0x0/0x230
[ 606.970245] [<c0450a90>] ? dev_watchdog+0x0/0x230
[ 606.970253] [<c01468f7>] __do_softirq+0x97/0x170
[ 606.970259] [<c015a9d6>] ? hrtimer_interrupt+0x186/0x1b0
[ 606.970265] [<c015a829>] ? ktime_get+0x19/0x40
[ 606.970272] [<c0146a2d>] do_softirq+0x5d/0x60
[ 606.970278] [<c0146ba5>] irq_exit+0x55/0x90
[ 606.970284] [<c011f8fb>] smp_apic_timer_interrupt+0x5b/0x90
[ 606.970292] [<c010ac2c>] apic_timer_interrupt+0x28/0x30
[ 606.970300] [<c0110a12>] ? mwait_idle+0x42/0x50
[ 606.970307] [<c010884d>] cpu_idle+0x6d/0xd0
[ 606.970314] [<c05091fe>] start_secondary+0xbe/0xf0
[ 606.970320] ---[ end trace 0ca83d030425275e ]---
[ 607.011677] r8169: eth0: link up
===========================

Same hardware, 2.6.28-15-server, same problem.

I'm going to try the latest version [http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc9/] of the kernel tonight and see if that resolves the issue.

I just upgraded to 2.6.31-020631rc9-generic and so far, all seems stable again...

amspilot (amspilot01) wrote :
Download full text (11.4 KiB)

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/buildd/linux-2.6.28/net/sched/sch_generic.c:226 dev_watchdog+0x270/0x280()
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> [<ffffffff80250ad7>] warn_slowpath+0xb7/0xf0
Sep 13 15:00:35 btrbl kernel: [ 270.920053] [<ffffffff805a5309>] ? sock_def_error_report+0x19/0x70
Sep 13 15:00:35 btrbl kernel: [ 270.920057] [<ffffffff8041751a>] ? __next_cpu+0x1a/0x30
Sep 13 15:00:35 btrbl kernel: [ 270.920059] [<ffffffff8041751a>] ? __next_cpu+0x1a/0x30
Sep 13 15:00:35 btrbl kernel: [ 270.920064] [<ffffffff80242502>] ? enqueue_entity+0x122/0x2b0
Sep 13 15:00:35 btrbl kernel: [ 270.920067] [<ffffffff8024881d>] ? enqueue_task_fair+0x3d/0x80
Sep 13 15:00:35...

amspilot (amspilot01) wrote :
Download full text (11.1 KiB)

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://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2
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-2.6.28-15-server
# 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]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
                ...

paul hoenecke (pmh009) wrote :

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 :

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)

I do not see this problem any longer with karmic and the 2.6.31 kernel.

Nicolas Picard (true255) wrote :

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 :

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 :

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 :

I have no issues after upgrading to Karmic.

Download full text (5.0 KiB)

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://bugs.launchpad.net/bugs/347711
> 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-2.6.28-11-generic
>
> Related to this bug:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=12411
>
> andres@testinserver1:~$ lsb_release -rd
> Description:    Ubuntu jaunty (development
> branch)
> Release:        9.04
>
> Mainboard/Processor: D945GCLF2 / Atom 330
>
> 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/buildd/linux-2.6.28/net/sched/sch_generic.c:226
> dev_watchdog+0x219/0x230()
> [  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...

Read more...

Download full text (8.9 KiB)

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://bugs.launchpad.net/bugs/347711
>> 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-2.6.28-11-generic
>>
>> Related to this bug:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=12411
>>
>> andres@testinserver1:~$ lsb_release -rd
>> Description:    Ubuntu jaunty (development
>> branch)
>> Release:        9.04
>>
>> Mainboard/Processor: D945GCLF2 / Atom 330
>>
>> 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/buildd/linux-2.6.28/net/sched/sch_generic.c:226
>> dev_watchdog+0x219/0x230()
>> [  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...

Read more...

Download full text (9.4 KiB)

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://bugs.launchpad.net/bugs/347711
>>> 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-2.6.28-11-generic
>>>
>>> Related to this bug:
>>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=12411
>>>
>>> andres@testinserver1:~$ lsb_release -rd
>>> Description:    Ubuntu jaunty (development
>>> branch)
>>> Release:        9.04
>>>
>>> Mainboard/Processor: D945GCLF2 / Atom 330
>>>
>>> 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/buildd/linux-2.6.28/net/sched/sch_generic.c:226
>>> dev_watchdog+0x219/0x230()
>>> [  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...

Read more...

Raph (raph-redsonic) wrote :

Hi, I've same problem with kernel 2.6.31-14!

[ 11.633891] r8169: eth0: link down
[ 11.634259] ADDRCONF(NETDEV_UP): eth0: link is not ready

 *-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
       capabilities: pm vpd msi pciexpress bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full latency=0 link=yes multicast=yes port=MII speed=100MB/s
       resources: irq:27 ioport:e000(size=256) memory:ff820000-ff820fff memory:e4000000-e401ffff(prefetchable)

sascha (sascha-siebenlinden) wrote :

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 :

Same problem here with Kernel 2.6.31-14-generic-pae running on an Atom Digital Engine minibox. Just wanted to add that the same box running pfsense (router distr. based on a BSD flavor) has been rock solid for a 31 day uptime.

DaveR (daver-derdev) wrote :

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+,D1+,D2+,D3hot+,D3cold+)
  Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
 Kernel driver in use: forcedeth
 Kernel modules: forcedeth

herrht (herrht) wrote :

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 :
Download full text (68.9 KiB)

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> [<ffffffff810e00ae>] __alloc_pages_slowpath+0x54e/0x560
Mar 21 02:22:19 torrents kernel: [ 3082.885930] [<ffffffff810e01ec>] __alloc_pages_nodemask+0x12c/0x130
Mar 21 02:22:19 torrents kernel: [ 3082.885947] [<ffffffff8110c882>] alloc_pages_current+0x82/0xd0
Mar 21 02:22:19 torrents kernel: [ 3082.885967] [<ffffffffa0026ef6>] try_fill_recv+0x136/0x1c0 [virtio_net]
Mar 21 02:22:19 torrents kernel: [ 3082.885974] [<ffffffffa002711d>] virtnet_poll+0xfd/0x150 [virtio_net]
Mar 21 02:22:19 torrents kernel: [ 3082.885982] [<ffffffff8143bd67>] net_rx_action+0x107/0x250
Mar 21 02:22:19 torrents kernel: [ 3082.886064] [<ffffffffa0026acd>] ? skb_xmit_done+0x4d/0x70 [virtio_net]
Mar 21 02:22:19 torrents kernel: [ 3082.886072] [<ffffffff8106511d>] __do_softirq+0xbd/0x200
Mar 21 02:22:19 torrents kernel: [ 3082.886078] [<ffffffff8101322c>] call_softirq+0x1c/0x30
Mar 21 02:22:19 torrents kernel: [ 3082.886083] [<ffffffff81014c05>] do_softirq+0x55/0x90
Mar 21 02:22:19 torrents kernel: [ 3082.886088] [<ffffffff81064e85>] irq_exit+0x85/0x90
Mar 21 02:22:19 torrents kernel: [ 3082.886092] [<ffffffff81014140>] do_IRQ+0x70/0xe0
Mar 21 02:22:19 torrents kernel: [ 3082.886104] [<ffffffff81012a53>] ret_from_intr+0x0/0x11
Mar 21 02:22:19 torrents kernel: [ 3082.886107] <EOI> [<ffffffff810356f6>] ? native_safe_halt+0x6/0x10
Mar 21 02:22:19 torrents kernel: [ 3082.886127] [<ffffffff8101a1dc>] ? default_idle+0x4c/0xe0
Mar 21 02:22:19 torrents kernel: [ 3082.886149] [<ffffffff8152cfa5>] ? atomic_notifier_call_chain+0x15/0x20
Mar 21 02:22:19 torrents kernel: [ 3082.886155] [<ffffffff81010e42>] ? cpu_idle+0xb2/0x100
Mar 21 02:22:19 torrents kernel: [ 3082.886164] [<ffffffff81515ab6>] ? rest_init+0x66/0x70
Mar 21 02:22:19 torrents kernel: [ 3082.886202] [<ffffffff8183c039>] ? start_kernel+0x352/0x35b
Mar 21 02:22:19 torrents kernel: [ 3082.886280] [<ffffffff8183b59a>] ? x86_64_start_reservations+0x125/0x129
Mar 21 02:22:19 torrents kernel: [ 3082.886286] [<ffffffff8183b698>] ? x86_64_start_kernel+0xfa/0x109
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_file:102872 unevictable:0 dirty:654 writeback:0 unstable:2802
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 :

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

dancelover (dancelover) wrote :

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]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8168, r8169

Solved compiling r8168 module from realteck site
HowTo --> http://ubuntuforums.org/showthread.php?t=1022411
(do make & make install as root)

Rechner-Tester (cs-rechner) wrote :

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 :

Same problem with

RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

Daugl (d-laurent) wrote :

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 :

I could lately "fix" this problem by deactivating the energy saving option for the corresponding LAN port in the Router/Modem/Switch/AP-Box (AVM FritzBox 3270, FW: 96.04.80).
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 :

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 :

file containing hardware details and log messages

sirio81 (sirio81) wrote :

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 :

sorry, also with sqeeze I have the same problem.
I hope it's not a hardware related problem.

Johan (ignesia) wrote :

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 :

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://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/141343
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/221499
https://bugs.launchpad.net/linux/+bug/347711

DanieW (dawessels) wrote :

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/2.6.38-8-generic/kernel/drivers/net/r8169.ko
firmware: rtl_nic/rtl8168d-2.fw
firmware: rtl_nic/rtl8168d-1.fw
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <email address hidden>
srcversion: B5846A288645E4180E09C87
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
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://forums.gentoo.org/viewtopic-t-819917.html?sid=159bc8f7f8599eec774e32999aba9575
for the Realtek option I am about to try

DanieW (dawessels) wrote :

Yes, that RealTek driver worked nicely (.. for eth0), installation was very easy: sudo bunzip2 r8168-8.024.00.tar.bz2 ; sudo tar xvf r8168-8.024.00.tar; cd r8168-8.024.00/; sudo ./autorun.sh
.... 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/

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 :

This bug is still present in Linux-2.6.35-30-generic. But his behaviour is curious. This bug never affected my GA-EP35-DS3R I bought more than 3 years ago (many Ubuntu revision since), but DOES affect my new mobo Gigabyte PH67-D3-B3. Solved by adding a marvell NIC PCI.

Changed in linux:
status: Confirmed → Incomplete
William King (quentusrex) wrote :

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 :

@William King: Please report your findings to the upstream kernel bug report.

https://bugzilla.kernel.org/show_bug.cgi?id=12411

Changed in linux:
status: Incomplete → Expired
DanieW (dawessels) wrote :

No, why? Why report it to https://bugzilla.kernel.org/show_bug.cgi?id=12411
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(NETDEV_UP): eth0: link is not ready
[ 12.413348] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 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(NETDEV_UP): eth0: link is not ready
[ 101.927170] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 101.930823] r8169 0000:04:06.0: eth4: link down
[ 101.930828] r8169 0000:04:06.0: eth4: link down
[ 101.930981] ADDRCONF(NETDEV_UP): eth4: link is not ready
[ 101.931292] ADDRCONF(NETDEV_UP): eth4: link is not ready
[ 104.702200] r8169 0000:04:06.0: eth4: link up
[ 104.702368] ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready
[ 137.301220] [UFW BLOCK] IN=eth4 OUT= MAC=f0:7d:68:c2:yy:yy:yy:6f:65:93:d4:dd:08:00 SRC=192.168.22.22 DST=192.168.22.24 LEN=423 TOS=0x00 PREC=0x00 TTL=128 ID=32305 PROTO=UDP SPT=1900 DPT=51722 LEN=403

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.