Distribution: Debian 3.0 (up-to-date) Hardware Environment: Motherboard Tyan S2707GNN Software Environment: Kernel home made Problem Description: the integrated e1000 card is not detected anymore by the linux kernel. As a consequence, eth0 is not present ! With the kernel-2.4.21, e1000 is fully detected and working perfectly. Steps to reproduce: boot a kernel configured with http://www.deep-ocean.net/~olive/linux/config-2.4.23-e1000-faulty Note: With CONFIG_E1000_NAPI=y, the problem is the same. I'm now compiling a kernel with e1000 as a module to see what the module says when modprobing.
Can you please try 2.6.0-test11 plus the following patch? http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test11-bk11-netdrvr-exp2.patch.bz2
Cannot test before saturday ! but i will as soon as possible.
I saw that issue on a couple of dual CPU motherboards with integrated e1000. I fixed it by passing the : noapic parameter on the linux boot. Steph
Hello, this is really a bug, i've got the problem with <b>2.4.25-rc1</b> kernel too ... please correct this bug before 2.4.25 release. With two e1000 on mainboard only one is detected and usable :( 2.4.21 kernel is ok but poor security. noapic kernel parameter does not resolv this problem. Board: Tyan S2707G2N (two gigabit ports)
This is the same problem with 2.6.0, 2.6.1 and 2.6.2 with and without noapic kernel param :( Here is a strange thing: lspci on 2.6.2 and 2.4.25-rc1: 00:00.0 Host bridge: ServerWorks: Unknown device 0017 (rev 32) 00:00.1 Host bridge: ServerWorks: Unknown device 0017 00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:08.0 Ethernet controller: Intel Corp.: Unknown device 100e (rev 02) 00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05) 00:0f.3 Host bridge: ServerWorks: Unknown device 0225 00:10.0 Host bridge: ServerWorks: Unknown device 0101 (rev 05) 00:10.2 Host bridge: ServerWorks: Unknown device 0101 (rev 05) lspci on 2.4.21 (two e1000 works well): 00:00.0 Host bridge: ServerWorks: Unknown device 0017 (rev 32) 00:00.1 Host bridge: ServerWorks: Unknown device 0017 00:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:08.0 Ethernet controller: Intel Corp.: Unknown device 100e (rev 02) 00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05) 00:0f.3 Host bridge: ServerWorks: Unknown device 0225 00:10.0 Host bridge: ServerWorks: Unknown device 0101 (rev 05) 00:10.2 Host bridge: ServerWorks: Unknown device 0101 (rev 05) 02:07.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01) On 2.4.21 there is a 02:07.0 device ! What could i do to help you resolving this problem ?
Hmmmmmm, it seems to be not a "bug" in e1000 driver but in apic/acpi/smp/other (i'm sorry i'm not a kernel hacker yet) ... Here is a new information, with 2.6.2 it works well (two e1000 eth): i remove acpi, smp and ioapic from kernel and my two e1000 works very well ! I try with 2.4.25-rc1 in 2 hours, more informations at this time.
is there a failure in the latest 2.4 or latest 2.6, or do they both work and we should close this? thanks, -Len
Please test 2.4.26 or 2.6.5 -- thanks, -Len
This is the same problem with 2.4.26 Tyan S2707G2N with two gigabit ports ! With ACPI stuff in kernel only one e1000 card is detected and enabled. If i remove all acpi stuff from kernel everything is OK.
This may be a duplicate of bug 1662 -- the infamous _BBN-0 bug. Please attach dmesg from ACPI+IOAPIC mode (where we see the failure) as well as the output from acpidmp, available in /usr/sbin/, or in pmtools: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
still a problem in 2.6.6? If yes, please attach the info requested above. Also, please try "pci=noacpi" in 2.6.6. thanks, -Len
no reply in a month, assuming this is a duplicate of bug 1662. If that turns out not to be the case, feel free to re-open. *** This bug has been marked as a duplicate of 1662 ***