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.
This is one ugly scenario. Interesting that it’s been around since 2005 but you’re only seeing it now.
Link | August 17th, 2007 at 3:11 pm
I had exactly the same thing happen to mine. Your solution fixed it.
Link | September 7th, 2007 at 9:59 am
You need to post description and details to the linux kernel mailing list.
Link | September 7th, 2007 at 10:07 am
Hm. Same problem. Microsoft business looks durty. Like everytime.
Solution – change driver to Realtek’s (by “choose”)
Link | September 14th, 2007 at 11:44 am
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.
Link | September 23rd, 2007 at 5:09 am
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
Link | October 2nd, 2007 at 2:33 am
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.
Link | October 8th, 2007 at 7:25 am
works for me too! 12 hours wasted doing other crap!
Link | October 19th, 2007 at 3:02 pm
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.
Link | November 20th, 2007 at 7:54 pm
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 2.6.23.1-49 still breaks.
Link | November 27th, 2007 at 2:25 pm
very interesting, but I don’t agree with you
Idetrorce
Link | December 15th, 2007 at 10:18 pm
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.
Link | December 19th, 2007 at 4:23 am
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.
Link | January 13th, 2008 at 1:40 am
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!!!!!!!!!
Link | February 6th, 2008 at 6:52 am
I just had the same problem with a VIA 6803 nic on a K9MMV motherboard from MSI.
I updated to kernel-2.6.24.3 and put pci=noacpi in grub.conf
Fixed for me.
YMMV
Link | March 14th, 2008 at 10:43 am
Hi
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.
Link | March 22nd, 2008 at 9:38 am
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?
Link | May 17th, 2008 at 10:44 am
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.
Link | June 26th, 2008 at 1:42 pm
Please HELP – I NOT use windows – help my – how i setting WAKE-ON-LAN under linux?
Link | July 4th, 2008 at 4:50 am
Thanx a lot. Switching to another driver helped!
Link | July 14th, 2008 at 1:05 am
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.
Link | July 22nd, 2008 at 6:35 am
Thank you VERY MACH!!!!!!!
Option pci=noacpi in grub.conf HELPS ME TOO!!!
Link | November 2nd, 2008 at 8:44 am
WOL worked for me, too.
Link | January 26th, 2009 at 8:04 am
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.
Link | October 12th, 2009 at 2:19 am
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.
Link | February 22nd, 2010 at 9:51 pm
I have this problem, (same deriver and error ) if I make sleepy my windows in dualboot. (openSUSE 11.0)
Link | January 17th, 2011 at 12:18 pm