Bug 576058 - eth0 (r8169): transmit queue 0 timed out
Summary: eth0 (r8169): transmit queue 0 timed out
Keywords:
Status: CLOSED DUPLICATE of bug 538920
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 572252 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-23 06:31 UTC by Pat Gunn
Modified: 2010-04-25 09:25 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-04-25 09:25:01 UTC
Type: ---
Embargoed:


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

Description Pat Gunn 2010-03-23 06:31:11 UTC
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 06:31:56 UTC
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 18:57:38 UTC
*** Bug 572252 has been marked as a duplicate of this bug. ***

Comment 3 Pat Gunn 2010-04-04 19:27:22 UTC
Update to my earlier comment - I never say this problem in Fedora 11 (I skipped Fedora 12). If this and fred2's problem are really the same, then the bug probably was introduced between Fedora 11 and Fedora 12.

Comment 4 fred2 2010-04-14 14:59:37 UTC
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-16 03:21:15 UTC
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-16 03:23:59 UTC
Created attachment 406978 [details]
output of lspci -vvn

Ethernet controller is last in the listing.

Comment 7 K Killebrew 2010-04-18 00:12:35 UTC
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 09:25:01 UTC

*** 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.