This question is a continuation of this one.

I've been having a ton of problems with my Ethernet chipset and e1000e driver:

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller

Apparently, it doesn't work at all without pcie=off, and even with the option it doesn't work after I resume from a suspend. Does anyone have any advice on this? Is it an upstream bug? Here is what happens when I try to resume and use my Ethernet card from dmesg.

If you want to see the results of numerous diagnostic tools be sure to check out my previous question which has a ton of information about my configuration.

[20837.993481] e1000e 0000:02:00.0: eth0: Detected Hardware Unit Hang:
[20837.993485]   TDH                  <55>
[20837.993488]   TDT                  <7b>
[20837.993490]   next_to_use          <7b>
[20837.993492]   next_to_clean        <54>
[20837.993494] buffer_info[next_to_clean]:
[20837.993496]   time_stamp           <4e4097>
[20837.993498]   next_to_watch        <55>
[20837.993501]   jiffies              <4e58a2>
[20837.993503]   next_to_watch.status <0>
[20837.993505] MAC Status             <80080703>
[20837.993507] PHY Status             <796d>
[20837.993510] PHY 1000BASE-T Status  <4000>
[20837.993512] PHY Extended Status    <3000>
[20837.993514] PCI Status             <10>
[20838.001038] ------------[ cut here ]------------
[20838.001055] WARNING: at /build/buildd/linux-2.6.35/net/sched/sch_generic.c:258 dev_watchdog+0x1fd/0x210()
[20838.001061] Hardware name: 170469U
[20838.001065] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[20838.001070] Modules linked in: usbhid hid aes_i586 aes_generic binfmt_misc parport_pc ppdev arc4 i915 thinkpad_acpi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi pcmcia snd_rawmidi ath5k snd_seq_midi_event mac80211 drm_kms_helper snd_seq ath snd_timer snd_seq_device sierra drm tpm_tis cfg80211 usbserial sbp2 tpm snd yenta_socket pcmcia_rsrc nvram i2c_algo_bit tpm_bios ieee1394 psmouse pcmcia_core intel_agp video serio_raw agpgart soundcore snd_page_alloc output lp parport e1000e firewire_ohci sdhci_pci firewire_core sdhci led_class crc_itu_t
[20838.001178] Pid: 0, comm: swapper Not tainted 2.6.35-28-generic #49-Ubuntu
[20838.001183] Call Trace:
[20838.001195]  [<c014aff2>] warn_slowpath_common+0x72/0xa0
[20838.001204]  [<c050fbdd>] ? dev_watchdog+0x1fd/0x210
[20838.001211]  [<c050fbdd>] ? dev_watchdog+0x1fd/0x210
[20838.001220]  [<c014b0c3>] warn_slowpath_fmt+0x33/0x40
[20838.001228]  [<c050fbdd>] dev_watchdog+0x1fd/0x210
[20838.001237]  [<c016c591>] ? sched_clock_cpu+0x131/0x190
[20838.001247]  [<c01696db>] ? hrtimer_forward+0x16b/0x1b0
[20838.001255]  [<c050f9e0>] ? dev_watchdog+0x0/0x210
[20838.001262]  [<c01581ef>] call_timer_fn+0x2f/0xf0
[20838.001270]  [<c012249b>] ? lapic_next_event+0x1b/0x20
[20838.001279]  [<c017486b>] ? clockevents_program_event+0x8b/0x140
[20838.001287]  [<c0159464>] run_timer_softirq+0x104/0x210
[20838.001296]  [<c0175c72>] ? tick_dev_program_event+0x42/0x150
[20838.001304]  [<c050f9e0>] ? dev_watchdog+0x0/0x210
[20838.001312]  [<c015164c>] __do_softirq+0x9c/0x1b0
[20838.001319]  [<c016c69e>] ? sched_clock_tick+0x5e/0x90
[20838.001328]  [<c01517a5>] do_softirq+0x45/0x50
[20838.001335]  [<c0151915>] irq_exit+0x65/0x70
[20838.001343]  [<c05d146b>] smp_apic_timer_interrupt+0x5b/0x8a
[20838.001352]  [<c05cb275>] apic_timer_interrupt+0x31/0x38
[20838.001361]  [<c016007b>] ? sys_setregid+0xeb/0xf0
[20838.001371]  [<c03bfd60>] ? acpi_idle_enter_bm+0x259/0x295
[20838.001381]  [<c04d396a>] cpuidle_idle_call+0x6a/0x100
[20838.001389]  [<c0101fcc>] cpu_idle+0x8c/0xd0
[20838.001398]  [<c05c5b16>] start_secondary+0x10c/0x112
[20838.001404] ---[ end trace 93e790a0cd7b9ac8 ]---
[20838.001423] e1000e 0000:02:00.0: eth0: Reset adapter
[20838.175627] e1000e: eth0 NIC Link is Up 10 Mbps Full Duplex, Flow Control: RX/TX
[20838.175637] e1000e 0000:02:00.0: eth0: 10/100 speed: disabling TSO

closed as off-topic by HopelessN00b Feb 20 '15 at 5:43

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow." – HopelessN00b
If this question can be reworded to fit the rules in the help center, please edit the question.

locked by HopelessN00b Feb 20 '15 at 5:43

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.

  • I had an issue with broadcom where I would lose n/w connectivity randomly. I disabled the MSI-x for the device interrupt and it went away. grep eth /proc/interrupts, you will see your device ises either APIC or MSI-x. To disable the MSI-x, add "options <device-name> disable_msi=1" to /etc/modprobe.conf and restart. – Prashanth Sundaram May 4 '11 at 16:19

Looks identical to this might. It does indeed appear to be an upstream bug. Check changelogs related to the e1000 driver, see if there's a patch you can back port or at least point the ubuntu kernel team to it. Try to bring your eth0 down, modprobe -r the driver before suspending, see if that's a potential work around. It may help upstream driver maintainers zero in on the bug.


I also had problems with e1000 and SLES10 SP4 until in late August 2011 this was fixed by a kernel-patch. The workaround until then: Download the newest driver from Intel, compile it and install it.

My specific problem was that the e1000 did not fall back to the standard-PCIe-mode (which did not seem to work even when forced) when MSI was not available (within the XEN-kernel).

Not the answer you're looking for? Browse other questions tagged or ask your own question.