7

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
Community
  • 1
Evan Carroll
  • 2,373
  • 10
  • 34
  • 53
  • 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 disable_msi=1" to /etc/modprobe.conf and restart. – Prashanth Sundaram May 04 '11 at 16:19

2 Answers2

1

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.

Ben Lutgens
  • 351
  • 1
  • 4
0

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

Nils
  • 7,695
  • 3
  • 34
  • 73