Red Hat Bugzilla – Bug 162102
rdesktop causes eth0: Transmit timed out
Last modified: 2013-03-05 22:43:52 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050511 Description of problem: Seems very strange to me, but I can not help myself - when I start rdesktop to remote XP machine, the connection starts very soon to be pretty chopping. I could not find why, but then I found in log: NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 00000100, resetting... Rx ring ffff81001edc8000: 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 Tx ring ffff81001eda0000: 80000000 0000 80000000 80000000 80000000 80000000 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 00000000, resetting... Rx ring ffff81001edc8000: 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 Tx ring ffff81001eda0000: 80000000 80000000 80000000 0000 80000000 80000000 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, status 00000000, resetting... Rx ring ffff81001edc8000: 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 80000000 Tx ring ffff81001eda0000: 80000000 80000000 80000000 80000000 80000000 0000 This eth card is pretty tested, and there is not other traffic I know that could cause this problems. This is fealnx eth driver with distribution kernel for FC4. Version-Release number of selected component (if applicable): rdesktop-1.4.0-2, kernel-2.6.11-1.1369_FC4 How reproducible: Always Steps to Reproduce: 1. rdesktop <machine> 2. login (if you can) 3. watch traffic and log message Actual Results: The connection to remote machine works, but freezes for few seconds every time this message appears. Expected Results: Normal operation. I used this with FC2 (i386 not x86_64) and worked well. Additional info: I you feel this is nonsence or should be assigned somewhere else, feel free to do that.
I found one thing that could brink some light to this: There is also often a message: "Losing some ticks... checking if CPU frequency changed." Page: http://www.ibiblio.org/peanut/Kernel-2.6.12/x86_64/boot-options.txt describes it as: " report_lost_ticks Report when timer interrupts are lost because some code turned off interrupts for too long."
Changing to kernel as it is not for sure a rdesktop's fault, it only causes that it shows much more often. Also different transfers are causing this. I experience it also with newer or vanila kernels. Could it be a x86_64 fealnx driver issue?
I tried with i386 distro, and problem also exhibits itself, probably hardware issue of myson based network card and nforce4.:(