e1000 driver not working properly on x86_64?

Bug #56885 reported by Herbert V. Riedel
8
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.15 (Ubuntu)
Invalid
Undecided
Ben Collins
linux-source-2.6.15 (Ubuntu)
Fix Released
Medium
Ben Collins
linux-source-2.6.17 (Ubuntu)
Fix Released
Undecided
Ben Collins

Bug Description

on a freshly installed dapper/x86_64 install, the e1000 supported intel Intel Pro/1000 PT
Server NIC was detected and configured, link gets detected, but it doesn't seem to receive ethernet frames (although the RX packet counters do increase, but no rx frame shows up in tcpdump)

alas it's a remote system which I don't have physical access to right now, so I can't easily try out a 32bit kernel, in order to verify my suspicion that it's simply a 64bit-bug kernel driver bug...

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 36
model name : AMD Turion(tm) 64 Mobile Technology MT-37
stepping : 2
cpu MHz : 803.680
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 1609.81
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

0000:00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: f7000000-f8ffffff
        Prefetchable memory behind bridge: 0000000030000000-0000000030000000
        Capabilities: <available only to root>

0000:02:00.0 Ethernet controller: Intel Corporation: Unknown device 107d (rev 06)
        Subsystem: Intel Corporation: Unknown device 1082
        Flags: bus master, fast devsel, latency 0, IRQ 225
        Memory at f8020000 (32-bit, non-prefetchable) [size=128K]
        Memory at f8000000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at b000 [size=32]
        Expansion ROM at 30000000 [disabled] [size=128K]
        Capabilities: <available only to root>

Linux version 2.6.15-26-amd64-generic (buildd@king) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Thu Aug 3 02:52:35 UTC 2006
[..]

Intel(R) PRO/1000 Network Driver - version 7.0.33-k2
Copyright (c) 1999-2005 Intel Corporation.
ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC5] -> GSI 16 (level, low) -> IRQ 225
PCI: Setting latency timer of device 0000:02:00.0 to 64
e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:17:0b:ff:e5
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection

Changed in linux-source-2.6.15:
importance: Untriaged → Medium
Revision history for this message
Herbert V. Riedel (hvr) wrote :

the following thread seems to be related:

http://ubuntuforums.org/showthread.php?t=242159

Revision history for this message
Herbert V. Riedel (hvr) wrote :

I've tried with intel's 7.2.7 e1000 version, but still no luck:

packets exit the ethernet adapter on the wire, and also show up in tcpdump, but no ethernet frame seems to get received from the wire (although still getting increased frame-rx counters...)

Revision history for this message
Herbert V. Riedel (hvr) wrote :

mystery solved:

MSI-PCI Interrupts weren't triggered... (/proc/interrupts showed always zero interrupts), and the frame statistics are updated through a kernel-timer-invoked update-function by reading NIC internal registers holding the required statistics data...

by compililing the driver with "make CFLAGS_EXTRA=-DDISABLE_PCI_MSI" and therefore falling back to 'IO-APIC' interrupts, frames started to show up in the network stack :-)

so now it seems to me, that it's just a matter of incomplete/broken MSI support with the involved chipsets... :-/

Revision history for this message
Ben Collins (ben-collins) wrote :

This change will show up soon in dapper-proposed.

I didn't remove the capability for MSI to work, but it's disabled by default now. Re-enable by doing enable_msi=1 when loading the module (for anyone that knows it works, or wants to find out).

Changed in linux-source-2.6.15:
assignee: nobody → ben-collins
status: Unconfirmed → Fix Committed
Changed in linux-source-2.6.17:
assignee: nobody → ben-collins
status: Unconfirmed → Fix Committed
Changed in linux-source-2.6.15:
status: Fix Committed → Fix Released
Changed in linux-source-2.6.15:
status: Fix Released → Fix Committed
Changed in linux-source-2.6.15:
status: Fix Committed → Fix Released
Changed in linux-restricted-modules-2.6.15:
assignee: nobody → ben-collins
status: New → Fix Released
Changed in linux-restricted-modules-2.6.15:
status: Fix Released → Invalid
Changed in linux-source-2.6.15:
status: Fix Released → Fix Committed
Changed in linux-source-2.6.17:
status: Fix Committed → Fix Released
Martin Pitt (pitti)
Changed in linux-source-2.6.15:
status: Fix Committed → In Progress
Changed in linux-source-2.6.15:
status: In Progress → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

linux-source-2.6.15 (2.6.15-51.63) dapper-proposed; urgency=low

  * Fix kernel-versions for ABI bump
  * Fix for kernel crash on lvremove
    - LP: #103729
  * e1000: Disable MSI by default. Allow it to be enabled with module param.
    Some chip implementations seem to not work well with MSI.
    - LP: #56885
  * tg3: Backport from 2.6.16.y
    - LP: #72696
  * Add r1000 to nic-modules
    - LP: #81782
  * Add bnx2 to nic-modules
    - LP: #73647
  * usb-serial: Fix oops with pilot-link
    - LP: #39518
  * megaraid: Move AMI/Megaraid3 IDs from megaraid_mbox.ko to megaraid.ko
    - LP: #57233

 -- Ben Collins <email address hidden> Tue, 23 Oct 2007 16:57:09 -0400

Please test and give feedback here.

description: updated
Revision history for this message
Kevin Harriss (kharriss-id) wrote :

I am having a similar problem with the Intel Pro 1000 PT desktop card. Here is the output of lspci:

0000:05:00.0 Ethernet controller: Intel Corporation: Unknown device 10b9 (rev 06)

This is after updating my kernel to the one from dapper-proposed. So the kernel update didn't fix my problem.

Revision history for this message
Kevin Harriss (kharriss-id) wrote :

I booted off of a Feisty cd (7.04) and the network card worked fine. So this problem is only with Dapper.

Revision history for this message
Kevin Harriss (kharriss-id) wrote :

I was wondering if there were any updates to this bug or if there is any more info I can provide to help fix this bug.

Revision history for this message
Martin Pitt (pitti) wrote :

Kevin, indeed you could help us by installing the kernel from dapper-proposed (just enable dapper-proposed and do a dist-upgrade) and tell us whether the e1000 card works then. Thank you!

Revision history for this message
Kevin Harriss (kharriss-id) wrote :

Martin, that is what I did and the card didn't work. I am not running dapper on this box any more as I needed to get the box up and running. It is currently running Gutsy and the e1000 card is working fine in Gusty.

Thanks,

Kevin

Revision history for this message
Brian Murray (brian-murray) wrote :

I downloaded the dapper daily build from 20071207.2 and booted from the CD. I was able to successfully get an IP address and wget a web page with the following network adapter on amd64:

04:00.0 Ethernet controller [0200]: Intel Corporation 82573L Gigabit Ethernet Controller [8086:109a] (rev 01)

Revision history for this message
Martin Pitt (pitti) wrote :

Fixed kernel is in dapper-updates now.

Changed in linux-source-2.6.15:
status: Fix Committed → Fix Released
Revision history for this message
KGordon (keir-keirgordon) wrote :

I'm having the exact problem described above in 8.04 x64. Not finding much info out there. Any ideas? Any info I can post to help?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.