NETDEV WATCHDOG transmit timed out, Realtek 8139

Periodically I restart my dual-boot workstation into Windows XP, run Microsoft Update and all other updaters to get everything current, then take a spin around the block just to make sure XP is still working fine. Among other updates this time, I accepted a new Realtek device driver from Microsoft Update. Normally, I only pull driver updates after they’ve been posted to Compaq support.

Win XP ran fine after all of the updates, but when I rebooted into openSUSE 10.2, it was unable to connect to the LAN. I found the following alarming entries in /var/log/messages:

  kernel: NETDEV WATCHDOG: eth0: transmit timed out
  kernel: eth0: Transmit timeout, status 0d 0000 c07f media 10.
  kernel: eth0: Tx queue start entry 4  dirty entry 0.
  kernel: eth0:  Tx descriptor 0 is 0008224e. (queue head)
  kernel: eth0:  Tx descriptor 1 is 0008224e.
  kernel: eth0:  Tx descriptor 2 is 0008224e.
  kernel: eth0:  Tx descriptor 3 is 0008024e.

Assuming that on-the-fly loading of the new driver by Windows XP plus a warm reboot had put the LAN chip in an undefined state, I did a full power-off reboot. No help. Perhaps my Linux configuration had been damaged coincidentally. To check, I rebooted a third time into an old, still functional SUSE 10.0 partition. It now failed with the same NETDEV errors. Anxiously, I rebooted into Windows XP, which still worked fine.

I was now faced with convincing evidence that a driver running under Windows XP was leaving the LAN interface firmware or hardware in a condition that could not be (or was not) properly re-initialized by Linux — something I would have dismissed as impossible had someone asked me prior to today.

Wanting my Linux back up as soon as possible, I ran Windows XP System Restore and rolled back out of the driver update. Holding my breath, I rebooted into openSUSE and found myself back on the LAN. Here are the before and after messages sections edited for easy comparison: messages-watchdog.txt and messages-normal.txt.

So Windows XP System Restore (which has saved my butt more than once) is the hero of this incident, with the problem likely in the Linux driver or the Realtek chip itself. I found 30K web hits on the error message, with this thread being the best match. No authoritative solution has appeared even though Linux users have been experiencing this problem consistently since 2005. Probably because debugging it would be a tedious, thankless task.

posted in opensuse, SysAdmin by Bozzie

26 Comments to "NETDEV WATCHDOG transmit timed out, Realtek 8139"

  1. TinasDancePartner wrote:

    This is one ugly scenario. Interesting that it’s been around since 2005 but you’re only seeing it now.

  2. Jeff wrote:

    I had exactly the same thing happen to mine. Your solution fixed it.

  3. Yakov wrote:

    You need to post description and details to the linux kernel mailing list.

  4. mondi wrote:

    Hm. Same problem. Microsoft business looks durty. Like everytime.
    Solution – change driver to Realtek’s (by “choose”)

  5. Cliff wrote:

    Same experience for me (but I haven’t restored the Microsoft Driver). However, for me, a full power down of the computer (unplugging from the wall) fixes the problem, until the next time I boot Windows.

  6. Luca Bertagnolio wrote:

    You saved my day! I was going nuts, rolling back kernel versions and all, and then the problem lied in the stupid Windows XP driver… unbelievable!

    Many thanks for your article, much appreciated.

    Ciao, Luca

  7. Zenon wrote:

    I just run into this problem myself. The easy workaround is to enable “wake on LAN” in the windoze driver’s properties. This will leave the card active on shutdown/reboot so linux can find it.

  8. Anonymous wrote:

    works for me too! 12 hours wasted doing other crap!

  9. ymr wrote:

    I hate to rain on this Microsoft bashing parade, BUT this NETDEV WATCHDOG timed out error happens regardless of whether Windows was booted since the previous cold boot.

    According to Debian derivatives, it is a bug in the Linux kernel and is fixed in 2.6.23 and later.

    Moreover, the original poster correctly noted -“with the problem likely in the Linux driver or the Realtek chip itself”.

    “Unplugging from the wall” – are you serious? Why don’t your rub your lucky rabbit foot next time.

  10. JamesDerrick wrote:

    I see the same issue with ‘NETDEV WATCHDOG: eth0: transmit timed out’ on multiple versions of Linux. Ubuntu 7.1, Knoppix, Fedora 7 & 8 all do the same.

    Interestingly, I have two identical motherboards. One _never_ runs Windows XP and works fine under Linux. The other dual-boots XP and fails. Both have identical recent BIOS and are on the same LAN switch.

    Lucky rabbit’s foot or not, a _hard_ reset with mains plug removed brings the XP dual-boot board up in Linux with Ethernet. A normal powerdown is not enough. I suspect Wake-on-LAN is keeping the Ethernet chipset powered and retaining bad config- this would explain the need for a power-off.

    Kernel still breaks.

  11. Idetrorce wrote:

    very interesting, but I don’t agree with you

  12. Karl Nyberg wrote:

    Unplugging, rolling back to a previous version, and setting the “wake on Lan” all failed for me (a PowerSpec 6400 Athlon 64 running Fedora 4). Can somebody tell me a specific driver version and location to download for Winders? My problems began when I upgraded the Bios to try to use 2x1GB modules (I can use 1x1GB and 1x512MB with either 1GB module, but 2x1GB fails to POST). Thanks.

  13. ivanatora wrote:

    I’m with kernel 2.6.23-9 and it just got NETDEV WATCHDOG: eth1 tramit timed out… So I assume it is not fixed in that version.
    And yes, I dual boot Windows XP, but I’ve never updated NIC drivers since I run it.
    That thing happened before several months (2.6.21 kernel that time) – it was happening all the time, and some *magic* got rid of it. I had some old kernel version in LILO, which did not have the problem. I *moved* that section above the kernel section I’m using and I never saw the problem again. I will say it again: the problem was solved simply by swapping two lilo sections. And yes, I have tried whole bunch of other solutions: ethtool, mii-tool, kernel versions switch…

    The saga continues: I’ve upgraded with 2.6.23-9 being on top of the LILO list, expecting to face that problem again but it never happened. I’ve not run XP so often, so maybe XP drivers are cousing it.
    Week ago I moved to my home place, where I had these troubles before. It just happened again.

    Here is another possible key besides the XP drivers key: the network the PC is operating in.

  14. paul wrote:

    i was having the same issues with the realtek 8139. at first when i would install ubuntu then restart the sytem it would not detect my NIC card as soon as enambled wake-on lan it worked!!!!!!!!!

  15. bithead wrote:

    I just had the same problem with a VIA 6803 nic on a K9MMV motherboard from MSI.
    I updated to kernel- and put pci=noacpi in grub.conf
    Fixed for me.

  16. nima0102 wrote:

    very thanks for your useful comments.
    I have the same problem.but I could not change the wake on lan feature on NIC in Windows.
    also I have tested ethtool in Linux in order to change wol.
    but neither have been helped to me.
    please give me guidance.

  17. Leo wrote:

    WHOOOHO!!! WAKE-ON-LAN Worked for me!!
    Thank you !
    but i wonder, why isn’t the linux driver enable this feature just like windows does?

  18. Serg wrote:

    You should be using a decent Linux distribution. I had the same experience with RedHat and Windows XP which required a cold restart to get RedHat working properly. Although Gentoo did not have any problems at all. Do not blame Windows if the Linux is to blame.

  19. Jorj wrote:

    Please HELP – I NOT use windows – help my – how i setting WAKE-ON-LAN under linux?

  20. T.G.A wrote:

    Thanx a lot. Switching to another driver helped!

  21. ivanatora wrote:

    Just to mention – the problem is not Windows specific. It is *Linux* specific. I have FreeBSD installed, and it doesn’t have troubles after restarts. BUT once I reboot from FreeBSD back to Linux and the problem is just there. So it doesn’t matter what OS are you dual booting – it’s faulty Linux driver. And no, the problem is NOT YET fixed into the kernel source tree.

  22. Nikiton wrote:

    Thank you VERY MACH!!!!!!!
    Option pci=noacpi in grub.conf HELPS ME TOO!!!

  23. Ron wrote:

    WOL worked for me, too.

  24. Andrea wrote:

    As ridiculous as it sounds, unplugging worked for me. Probably is the cruder way to make it work, just like wake onn lan. It is definitely related to wake on lan issues.

  25. glen wrote:

    The problem still exists in 2.6.30-gentoo-r6 … note this is gentoo, Serg. 🙂

    For me, pci=noacpi doesn’t help. Nor did disabling anything WOL-related from the Windows driver advanced config.

    But pulling the power cable (20 seconds or so) before booting linux repeatably works, while booting linux after Windows without pulling power repeatably doesn’t.

    I haven’t yet bothered to rollback the windows driver. Nor have I tracked down how to turn off WOL in linux yet.

    If, as some claim, their version of the kernel fixes this issue, it would be nice to get the exact kernel version, or better, the version (or patch) of the 8139 driver their kernel sources include.

  26. pavel wrote:

    I have this problem, (same deriver and error ) if I make sleepy my windows in dualboot. (openSUSE 11.0)

Powered by Wordpress and MySQL. Theme by