Bug 576058 - eth0 (r8169): transmit queue 0 timed out
eth0 (r8169): transmit queue 0 timed out
Status: CLOSED DUPLICATE of bug 538920
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 572252 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-23 02:31 EDT by Pat Gunn
Modified: 2010-04-25 05:25 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-25 05:25:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of lspci -vvn (18.52 KB, text/plain)
2010-04-15 23:23 EDT, K Killebrew
no flags Details

  None (edit)
Description Pat Gunn 2010-03-23 02:31:11 EDT
Description of problem:Occasionally the wired ethernet driver chokes on the system, giving a trap visible in dmesg and disabling the network device until system reboot (removing and reloading the module doesn't fix it). I never saw this problem in Fedora 12.


Version-Release number of selected component (if applicable):
2.6.33.1

How reproducible:
Occasional, maybe once every few days

Steps to Reproduce:
1.Normal system use, usually happens while running a network app (doesn't need to be anything particularly high-bandwidth)

  
Actual results:
Network connection dies and won't come back up. Dmesg can show error. NetworkManager detects a "link down" and then a "link up" event and then fails to detect any further link changes (even if restarted) - network device is useless at that point until a reboot (unloading and reloading module causes MAC address to be detected as FF:FF:FF:FF:FF..) 

Expected results:


Additional info:

dmesg:

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xfb/0x169()
Hardware name: HP HDX 18 Notebook PC
NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Modules linked in: fuse rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter  ip6_tables ipv6 uinput snd_hda_codec_nvhdmi arc4 snd_hda_codec_idt ecb snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device uvcvideo iwlagn snd_pcm videodev iwlcore v4l1_compat v4l2_compat_ioctl32 btusb mac80211 joydev bluetooth i2c_i801 snd_timer hp_wmi jmb38x_ms lirc_ene0100 hp_accel sdhci_pci        iTCO_wdt iTCO_vendor_support snd cfg80211 lis3lv02d sdhci lirc_dev memstick wmi input_polldev mmc_core r8169 soundcore rfkill mii snd_page_alloc            dm_multipath firewire_ohci firewire_core crc_itu_t video output nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: microcode]
Pid: 0, comm: swapper Not tainted 2.6.33-1.fc13.x86_64 #1
Call Trace:
 <IRQ>  [<ffffffff8105034c>] warn_slowpath_common+0x7c/0x94
 [<ffffffff810503bb>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff813e426d>] dev_watchdog+0xfb/0x169
 [<ffffffff8107d1ae>] ? trace_hardirqs_on_caller+0xf7/0x135
 [<ffffffff8105d54f>] run_timer_softirq+0x220/0x2e5
 [<ffffffff8105d4c2>] ? run_timer_softirq+0x193/0x2e5
 [<ffffffff8107baae>] ? lock_release_holdtime+0x34/0xe3
 [<ffffffff81010471>] ? native_sched_clock+0x2d/0x5f
 [<ffffffff813e4172>] ? dev_watchdog+0x0/0x169
 [<ffffffff81056a9d>] ? __do_softirq+0x76/0x1cd
 [<ffffffff81056b1f>] __do_softirq+0xf8/0x1cd
 [<ffffffff8100abdc>] call_softirq+0x1c/0x30
 [<ffffffff8100c3e3>] do_softirq+0x4b/0xa3
 [<ffffffff8105670a>] irq_exit+0x4a/0x8c
 [<ffffffff8147dfec>] do_IRQ+0xac/0xc3
 [<ffffffff81479013>] ret_from_intr+0x0/0x16
 <EOI>  [<ffffffff812a5801>] ? acpi_idle_enter_bm+0x26c/0x2a0
 [<ffffffff812a57fa>] ? acpi_idle_enter_bm+0x265/0x2a0
 [<ffffffff813a5066>] cpuidle_idle_call+0x9e/0xf8
 [<ffffffff81008c34>] cpu_idle+0xaf/0xe9
 [<ffffffff8147019a>] start_secondary+0x201/0x242
---[ end trace 85d82eb8c20166dc ]---


Relevant lspci -V:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
        Subsystem: Hewlett-Packard Company Device 3610
        Flags: bus master, fast devsel, latency 0, IRQ 31
        I/O ports at 5000 [size=256]
        Memory at d4010000 (64-bit, prefetchable) [size=4K]
        Memory at d4000000 (64-bit, prefetchable) [size=64K]
        Expansion ROM at d4020000 [disabled] [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169
Comment 1 Pat Gunn 2010-03-23 02:31:56 EDT
Oops, wasn't root when I did lspci. Fixed:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
        Subsystem: Hewlett-Packard Company Device 3610
        Flags: bus master, fast devsel, latency 0, IRQ 31
        I/O ports at 5000 [size=256]
        Memory at d4010000 (64-bit, prefetchable) [size=4K]
        Memory at d4000000 (64-bit, prefetchable) [size=64K]
        Expansion ROM at d4020000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
        Capabilities: [d0] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Kernel driver in use: r8169
        Kernel modules: r8169
Comment 2 fred2 2010-04-04 14:57:38 EDT
*** Bug 572252 has been marked as a duplicate of this bug. ***
Comment 3 Pat Gunn 2010-04-04 15:27:22 EDT
Update to my earlier comment - I never say this problem in Fedora 11 (I skipped Fedora 12). If this and fred2@qnet.com's problem are really the same, then the bug probably was introduced between Fedora 11 and Fedora 12.
Comment 4 fred2 2010-04-14 10:59:37 EDT
problem is still present in fedora 13 beta livecd x86_64
$ uname -a
Linux localhost.localdomain 2.6.33.1-24.fc13.x86_64 #1 SMP Tue Mar 30 18:21:22 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

note: yum shows a post-beta release kernel update is available (untested):
kernel-2.6.33.2-41.fc13.x86_64.rpm   12-Apr-2010 17:54   21M
Comment 5 K Killebrew 2010-04-15 23:21:15 EDT
Had no connectivity at all running f13 beta livecd x86_64 or initially with fresh install of beta to disk (ping times out with 'unknown host').  Then ran 'setenforce 0' and rebooted, and had a connection for a few minutes, until software update ran and crashed with kernel backtrace.  (Received several backtraces, similar to above.)

On first boot, received two messages regarding:
SELinux is preventing /usr/libexec/udisks-daemon "getattr" access

Using ECS A780GM-A board with Realtek RTL8111/8168B ethernet controller.

Attempting 'rmmod r8169 && modprobe r8169' fails with FF:FF:FF:FF:FF MAC address as described above; get 'SIOCSIFFLAGS: Cannot assign requested address' on attempting to bring up eth0 after module reload.
Comment 6 K Killebrew 2010-04-15 23:23:59 EDT
Created attachment 406978 [details]
output of lspci -vvn

Ethernet controller is last in the listing.
Comment 7 K Killebrew 2010-04-17 20:12:35 EDT
Tested on another system with same motherboard (ECS A780GM-A) as affected system, and had no problems with connectivity using onboard ethernet controller (gave it >10 min. of heavy Internet use).  It seems to be more than a hardware issue, however, as the affected system has no connectivity issues running ubuntu karmic or lucid beta2 (kernel 2.6.32-19).  Issue also present using fedora 12.

Tried using Realtek's driver (r8168) from:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

Got a few minutes of connectivity after login, as before, but then instead of simply losing connectivity, the system hard froze.

Dropped in a new NIC (Linksys, also using Realtek, r8169), and have good connectivity.

Smolt profile of affected system:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

SELinux issue mentioned in Comment 5 appears to be unrelated.
Comment 8 Eric Smith 2010-04-25 05:25:01 EDT

*** This bug has been marked as a duplicate of bug 538920 ***

Note You need to log in before you can comment on or make changes to this bug.