RTL-8029: NETDEV WATCHDOG: eth1: transmit timed out

With linux 2.6.17 there is no problem

Can you add "irqpoll" to the kernel command line arguments and try to reproduce it?

with "irqpoll" the computer freeze during the GNOME login

Please attach full dmesg.

dmesg log after the bug:

[11919.567929] NETDEV WATCHDOG: eth1: transmit timed out
[11919.567936] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=63.
[11919.967551] NETDEV WATCHDOG: eth1: transmit timed out
[11919.967560] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
[11920.566983] NETDEV WATCHDOG: eth1: transmit timed out
[11920.566996] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
[11920.966603] NETDEV WATCHDOG: eth1: transmit timed out
[11920.966613] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=77.
[11921.765843] NETDEV WATCHDOG: eth1: transmit timed out
[11921.765853] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
[11922.165467] NETDEV WATCHDOG: eth1: transmit timed out
[11922.165479] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=62.
[11922.964704] NETDEV WATCHDOG: eth1: transmit timed out
[11922.964713] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=87.
[11924.163563] NETDEV WATCHDOG: eth1: transmit timed out
[11924.163571] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
[11925.162617] NETDEV WATCHDOG: eth1: transmit timed out
[11925.162628] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=77.
[11928.759198] NETDEV WATCHDOG: eth1: transmit timed out
[11928.759208] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=96.
[11929.558438] NETDEV WATCHDOG: eth1: transmit timed out
[11929.558448] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=57.
[11931.156919] NETDEV WATCHDOG: eth1: transmit timed out
[11931.156930] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=80.
[11931.756352] NETDEV WATCHDOG: eth1: transmit timed out
[11931.756362] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=96.
[11937.550849] NETDEV WATCHDOG: eth1: transmit timed out
[11937.550859] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=315.
[11938.549894] NETDEV WATCHDOG: eth1: transmit timed out
[11938.549904] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
[11939.548945] NETDEV WATCHDOG: eth1: transmit timed out
[11939.548955] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=65.
[11942.346287] NETDEV WATCHDOG: eth1: transmit timed out
[11942.346296] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=265.
[11943.345340] NETDEV WATCHDOG: eth1: transmit timed out
[11943.345351] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=154.
[11946.342490] NETDEV WATCHDOG: eth1: transmit timed out
[11946.342501] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=264.
[11948.340596] NETDEV WATCHDOG: eth1: transmit timed out
[11948.340606] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=264.
[11950.338692] NETDEV WATCHDOG: eth1: transmit timed out
[11950.338702] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=263.
[11954.934329] NETDEV WATCHDOG: eth1: transmit timed out
[11954.934340] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=281.
[11957.531859] NETDEV WATCHDOG: eth1: transmit timed out
[11957.531867] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=431.
[11959.529963] NETDEV WATCHDOG: eth1: transmit timed out
[11959.529976] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=28...

The update make some days ago make the network bug after a few minutes rather than some hours

I'm seeing the same problem, and it would make me sad if it couldn't be resolved in time for the release of feisty...

I have same error, with similar logs
My system: Gigabyte GA-M61PS3 Sempron 3200+ 1GB ram RTL-8029(AS)

/var/log/messages/
Jun 7 13:45:48 ubuntu kernel: [ 1841.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:45:50 ubuntu kernel: [ 1843.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:47:49 ubuntu kernel: [ 1962.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:49:48 ubuntu kernel: [ 2081.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:49:50 ubuntu kernel: [ 2083.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:51:47 ubuntu kernel: [ 2199.292000] NETDEV WATCHDOG: eth1: transmit timed out
/var/syslog
Jun 7 13:47:49 ubuntu kernel: [ 1962.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:47:49 ubuntu kernel: [ 1962.092000] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0xb7, t=291.
Jun 7 13:49:48 ubuntu kernel: [ 2081.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:49:48 ubuntu kernel: [ 2081.092000] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0xb7, t=29541.
Jun 7 13:49:50 ubuntu kernel: [ 2083.092000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:49:50 ubuntu kernel: [ 2083.092000] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=291.
Jun 7 13:51:47 ubuntu kernel: [ 2199.292000] NETDEV WATCHDOG: eth1: transmit timed out
Jun 7 13:51:47 ubuntu kernel: [ 2199.292000] eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0xb7, t=251.

This bug does not appear on Knoppix 5.1

Similar here too. The machine disappears from the network until reboot. The card is

01:01.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
        Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at b800 [size=128]
        Region 1: Memory at e7dffc00 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at 50000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

The first sign of the problem in syslog is

Jun 23 05:36:51 bettyboop kernel: [585849.763346] NETDEV WATCHDOG: eth0: transmit timed out
Jun 23 05:36:51 bettyboop kernel: [585849.763356] eth0: transmit timed out, tx_status 00 status 8601.
Jun 23 05:36:51 bettyboop kernel: [585849.799305] diagnostics: net 0cc6 media 8880 dma 0000003a fifo 0000
Jun 23 05:36:51 bettyboop kernel: [585849.838385] eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Jun 23 05:36:51 bettyboop kernel: [585849.886389] Flags; bus-master 1, dirty 3633675(11) current 3633675(11)
Jun 23 05:36:51 bettyboop kernel: [585849.927012] Transmit list 00000000 vs. ffff81003de608e0.
Jun 23 05:36:51 bettyboop kernel: [585849.960383] 0: @ffff81003de60200 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585849.998432] 1: @ffff81003de602a0 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.036482] 2: @ffff81003de60340 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.074531] 3: @ffff81003de603e0 length 8000005f status 0c01005f
Jun 23 05:36:51 bettyboop kernel: [585850.112582] 4: @ffff81003de60480 length 8000005f status 0c01005f
Jun 23 05:36:51 bettyboop kernel: [585850.150632] 5: @ffff81003de60520 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.188682] 6: @ffff81003de605c0 length 8000005f status 0c01005f
Jun 23 05:36:51 bettyboop kernel: [585850.226732] 7: @ffff81003de60660 length 8000005f status 0c01005f
Jun 23 05:36:51 bettyboop kernel: [585850.264782] 8: @ffff81003de60700 length 8000002a status 0001002a
Jun 23 05:36:51 bettyboop kernel: [585850.302832] 9: @ffff81003de607a0 length 8000002a status 8001002a
Jun 23 05:36:51 bettyboop kernel: [585850.340882] 10: @ffff81003de60840 length 8000002a status 8001002a
Jun 23 05:36:51 bettyboop kernel: [585850.379452] 11: @ffff81003de608e0 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.418021] 12: @ffff81003de60980 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.456591] 13: @ffff81003de60a20 length 800005ea status 0c0105ea
Jun 23 05:36:51 bettyboop kernel: [585850.495160] 14: @ffff81003de60ac0 len...

Same problem, but with 2 network cards. They are a 3COM 3c900B-TPO Etherlink XL [Cyclone] and an nVidia MCP51 Ethernet Controller.
See also bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/109629

Same here in Ubuntu-Feisty server with kernel 2.6.20-15 and 2.6.20-16
First appeared with a RhineII (built-in) LAN adapter. I first thought it might be broken so I disabled it in Bios and replaced it with a Realtek (Ovislink-PCI card):
00:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
 with same effect.
/var/log/messages keeps repeating the following two lines:
Jul 23 16:50 cat kernel: [3809.056450] eth1: link up, 100Mbps, full duplex, lpa 0x45E1
Jul 23 16:50 cat kernel: [3874.948719] NETDEV WATCHDOG: eth1: transmit timed out

it seems to happen especially during heavy use, like copying / compressing files over LAN.

Today the bug struck here for the second time, about 6 weeks since the first time (comment 9).

Disabling ACPI support in the BIOS solved my problem.

I have the same problem with Feisty...
Lan is disabled after minutes or hours.

I have tried the pci=noacpi directive and I am looking for results, but up to now I see that this directive seems to cause troubles like disabling the sound...

I used Edgy on the same PC without a similar problem...

-

Here are parts of logs, when the problem happened before the adding of pci=noacpi.

kern

Sep 26 08:20:41 nom_pc kernel: [ 32.844000] Bluetooth: RFCOMM TTY layer initialized
Sep 26 08:20:41 nom_pc kernel: [ 32.844000] Bluetooth: RFCOMM ver 1.8
Sep 26 08:20:51 nom_pc kernel: [ 42.604000] /dev/vmnet: open called by PID 6108 (vmnet-netifup)
Sep 26 08:20:51 nom_pc kernel: [ 42.604000] /dev/vmnet: port on hub 8 successfully opened
Sep 26 08:20:51 nom_pc kernel: [ 42.616000] /dev/vmnet: open called by PID 6107 (vmnet-netifup)
Sep 26 08:20:51 nom_pc kernel: [ 42.620000] /dev/vmnet: hub 1 does not exist, allocating memory.
Sep 26 08:20:51 nom_pc kernel: [ 42.620000] /dev/vmnet: port on hub 1 successfully opened
Sep 26 08:20:51 nom_pc kernel: [ 42.748000] /dev/vmnet: open called by PID 6130 (vmnet-dhcpd)
Sep 26 08:20:51 nom_pc kernel: [ 42.748000] /dev/vmnet: port on hub 1 successfully opened
Sep 26 08:20:51 nom_pc kernel: [ 42.748000] /dev/vmnet: open called by PID 6119 (vmnet-dhcpd)
Sep 26 08:20:51 nom_pc kernel: [ 42.748000] /dev/vmnet: port on hub 8 successfully opened
Sep 26 08:21:01 nom_pc kernel: [ 52.652000] vmnet1: no IPv6 routers present
Sep 26 08:21:01 nom_pc kernel: [ 52.696000] vmnet8: no IPv6 routers present
Sep 26 08:22:41 nom_pc kernel: [ 152.304000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=81.88.55.99 DST=192.168.1.13 LEN=44 TOS=0x00 PREC=0x00 TTL=62 ID=44856 DF PROTO=TCP SPT=43198 DPT=5900 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 26 08:22:44 nom_pc kernel: [ 155.304000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=81.88.55.99 DST=192.168.1.13 LEN=44 TOS=0x00 PREC=0x00 TTL=62 ID=44857 DF PROTO=TCP SPT=43198 DPT=5900 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 26 09:03:54 nom_pc kernel: [ 2625.464000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=211.155.16.53 DST=192.168.1.13 LEN=48 TOS=0x00 PREC=0x00 TTL=104 ID=12884 PROTO=TCP SPT=65004 DPT=10000 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 26 09:49:25 nom_pc kernel: [ 5356.744000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=202.75.55.169 DST=192.168.1.13 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=17178 DF PROTO=TCP SPT=57410 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 26 09:49:28 nom_pc kernel: [ 5359.744000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=202.75.55.169 DST=192.168.1.13 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=17179 DF PROTO=TCP SPT=57410 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 26 10:12:38 nom_pc kernel: [ 6749.448000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=77.193.8.193 DST=192.168.1.13 LEN=48 TOS=0x00 PREC=0x00 TTL=120 ID=43150 DF PROTO=TCP SPT=3113 DPT=5900 WINDOW=64240 RES=0x00 SYN URGP=0
Sep 26 10:12:40 nom_pc kernel: [ 6751.832000] Inbound IN=eth0 OUT= MAC=00:10:5a:42:71:ef:00:16:b6:bd:00:e2:08:00 SRC=...

So, any idea when this bug will be fixed? Or suggestions wich kernel verion to choose?

Disabling ACPI using pci=noacpi directive in grub menu.lst did not fix my problem !

So I have removed this useless directive from my menu.lst.

I am back to Edgy, up to a reliable solution would fix this annoying Feisty bug.

I hope this bug will be fixed in Ubuntu 7.10 Gutsy so that I could migrate to a newer version than Edgy...

I do not know if it could help someone here: I'm on 64Studio (not Ubuntu) and I have a Realtek 8139 that gave a similar message today (netdev watchdog eth1: transmit out.

I finally found that a Windows Update (Realtek 8139 new driver) I made last week gave this weird result in my Linux partition... I rolled back the old driver in Windows and I had no more of these messages and my network is running fine again.

I found the solution at: http://bozziesfw.wordpress.com/2007/08/14/netdev-watchdog-timed-out-realtek-8139/

*To the administrator, if you find this message is not related in any way to this bug, do not hesitate to remove it.

Unfortunately this happens with a 3com 3c905 card and after a unpredicted period of time :(
I compiled a new kernel - 2.6.22.9 and I'm leaving the computer on for a long time to see if it will drop the network again, but so far it hadn't :)

I also use a 3com 3c905b NIC card in my PC, and I am sure that my problems are related to this component.

Do we have to replace this NIC card with a newer one and which ones could be the best choice for use in both Ubuntu and Vista ?

This NIC card WAS a famous and reliable one in the past, but I must admit that it generates some troubles both in Ubuntu Feisty and under Vista (impossible to find a reliable driver for Vista...) !

I've been using the new kernel 2.6.22.9 since yesterday and I have no drops or problems ;)

Unfortunately the bug is in the 2.6.22 kernel too :( It keeps occuring to me again.
I'll wait until the 2.6.23 kernel and see if they'd fix that in it :(

Kernel 2.6.23 is out! And guess what is in the changelog!

    Change INT0 trigger mode from edge-sense mode to level-sense mode,
    in order to fix the following timeout error:
      'NETDEV WATCHDOG: eth0: transmit timed out'.
Coool! :)

Running Gutsy (7.10) gives same intermittent network failure problem - and no problems at all under Windows XP

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
        Subsystem: ASRock Incorporation Unknown device 8168
        Flags: bus master, fast devsel, latency 0, IRQ 17
        I/O ports at e800 [size=256]
        Memory at febff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at febc0000 [disabled] [size=128K]
        Capabilities: <access denied>

I had the same problem with Gutsy and Asrock 945G-DVI but not with the Asus A2M-VM motherboard which has the same Realtek NIC.

POSSIBLE WORKAROUND:
For Asrock I tried everything, disabling acpi, updating BIOS and adding irqpoll to grub. Then again I disabled ACPI HPET-table from BIOS. It did not help by itself but when I added a bogus line (eth1 without auto eth1) to the "/etc/network/interfaces" the card started to work perfectly. Only thing is that now the computer does not shutdown correctly (it just displays 102.957386 Power down). So I have to shut it down from power button.

my "/etc/network/interfaces"

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface

iface eth0 inet static
address 199.111.1.100
netmask 255.255.255.0
gateway 199.111.1.1

auto eth0

# The secondary network interface

iface eth1 inet static #this is just bogus, I don't have another nic
address 199.111.1.100 #this is just bogus, I don't have another nic
netmask 255.255.255.0 #this is just bogus, I don't have another nic
gateway 199.111.1.1#this is just bogus, I don't have another nic

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I no longer use the same hardware and not able to perform the suggested
test...
Sorry for not being able to help the community on this.

I've just been assisting a user on #ubuntu who was experiencing this error message when trying to connect two PCs via cross-over cable.

There are a huge number of reports in forums blogs and mailing lists across the Internet, but few concrete solutions.

The best hints I could find were:

* disabling the Wake-on-LAN function in the system BIOS, and
* doing a complete cold boot - that means even disconnecting the power cable from the mains for 30 seconds (this ensure the 5V standby power is definitely removed) so the card loses any settings the standby + WOL mode might retain.

This second option solved the issue for the person I was assisting.

Also, some people report that on dual-boot systems with Windows, booting Windows and making sure it can use the network adapter, then doing a wam restart into Linux will also solve the issue temporarily.

As of today, with all updates, this is still a problem.

I have kept the output of lshw and the syslog for the period (see attachments). It looks to me like my two ethernet cards eth0/1 get swapped around from the irq point of view. Maybe this will help someone get a better understanding of the problem.

Hello.

I had this problem too, until today.

On high load my nic (realtek 8169) cut the connection. I've add acpi=off to the /boot/grub/menu.lst at the ende of the kernel line. After rebooting the system i have copy 10 GB and 27 GB to my server without any transmit error.

Perhaps somebody can solve the problem in the same way.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

This bug report is being closed because we received no response to the previous inquiry for information. Please reopen if this is still an issue in the current Ubuntu release, Jaunty Jackalope 9.04 - http://www.ubuntu.com/getubuntu/download. If the issue remains in Jaunty, please test the latest upstream kernel build - https://wiki.ubuntu.com/KernelMainlineBuilds . To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.