Intel 82578DC Network Device not detected

dxbydt · #1 2009-11-03, 11:32 AM CST

I just build a new computer with an Intel DP55WB desktop board which includes an integrated 82578DC network adapter. I've installed Fedora 11 but it is unable to detect my network adapter in any of the system configuration apps. ifconfig returns nothing but loop, ifup eth0 fails and says no device detected. lspci sees an intel gigabit network adapter with ven/dev 8086:10f0, but that's the only thing that seems to notice it exists. system-config-network shows nothing but pan0.

I'm using kernel 2.6.30.9-90 and NetworkManager 0.7.1.997-1. Any help would be greatly appreciated.

**stoat** · #2 2009-11-03, 12:50 PM CST

Hello dxbydt,

According to this...

http://cateee.net/lkddb/web-lkddb/E1000E.html

...that PCI-ID is supported by the e1000e kernel module which is included with Fedora 11...

Code:

$ modprobe --list | grep e1000
kernel/drivers/net/e1000/e1000.ko
kernel/drivers/net/e1000e/e1000e.ko

I would take a moment to look at the loaded modules to see if it's being loaded or if a some other possibly conflicting module is being loaded and can be removed and stopped from loading...

Code:

lsmod | sort

If it's not there, try loading it manually and restart NetworkManager...

Code:

su
modprobe e1000e
service NetworkManager restart

If that works, then you can try some things to make it loaded automatically.

stevea · #3 2009-11-03, 01:13 PM CST

If that doesn't work then please let us know.
See addendum below.
===

If the modprobe that Stoat suggest DOES work, then please look the the output of dmesg
dmesg | less
to see exactly what happened when the kernel initialized and there was an attempt to find a driver for the device. Something fail - it may be that the udevd tables are missing an entry.
===========
[added]

Your device ID has not yet been added to the 2.6.30.9 kernel.
http://git.kernel.org/?p=linux/kerne...e/hw.h;hb=HEAD
You still aren't stopped.

Load the e1000e driver using modprobe as Stoat described, the nyou can add your ID to the driver list like this:

modprobe e1000e
echo "8086 10f0" > /sys/bus/pci/drivers/e1000e/new_id

If that works then you can add the two lines to /etc/rc.d/rc.local
just edit this script and add the commands to end of file.

You might want to find a better place for these commands (perhaps in /etc/init.d/network) otherwise the network
configuration will precede the driver installation.

[added]
IF that works make a script in /etc/sysconfog/modules/ The filename should be "e1000e.modules"
put the two commands in there. This is executed very early.

dxbydt · #4 2009-11-03, 02:41 PM CST

I tried what Stoat suggested and the driver seems to load fine. Here is the output from dmesg.

e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.4-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.

However, after restarting NetworkManager there is still no network device listed. I tried adding the ven/dev id to the new_id like stevea suggested and it didn't seem to have any effect. This is the exact line from lspci.

00:19.0 Ethernet controller [0200]: Intel Corporation Device [8086:10f0] (rev 05)

Any other ideas? Is this device too new for the e1000e driver?

stevea · #5 2009-11-03, 05:52 PM CST

Quote:

Originally Posted by dxbydt

I tried what Stoat suggested and the driver seems to load fine. Here is the output from dmesg.

e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.4-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.

However, after restarting NetworkManager there is still no network device listed. I tried adding the ven/dev id to the new_id like stevea suggested and it didn't seem to have any effect. This is the exact line from lspci.

00:19.0 Ethernet controller [0200]: Intel Corporation Device [8086:10f0] (rev 05)

Any other ideas? Is this device too new for the e1000e driver?

First, I'm not certain that the e1000e supports this device without modification. I have little faith in the website that Stoat & Google report. My first hunch would be that the e1000 (not e1000e) would be the right one.

Next - you should ignore network manager until you get the system to report the interface correctly. Network Manager is a very complex and IMO still-too-fragile bit of code. It's entirely possible that NM is too dumb to recognize a new interface after it's started (as yo usurmised).

So there are two ways to search to see if the interface was created.
1/ ifconfig -a
2/ lspci -nnk

The first uses the socket interface and asks for all the interfaces. The second searches out the driver associated with each pci device (only a few lines are relevant).

===

As a test procedure I would suggest this:

A/ reboot
execute these commands:
modprobe e1000e
echo "8086 10f0" > /sys/bus/pci/drivers/e1000e/new_id
ifconfig -a
lscpi -nnk

Also look through the dmesg output like this:
dmesg | less

When you echo to new_id then the driver should be forced to associate with your device. *IF* the driver recognized the device and failed (maybe the driver can't handle this device) it must cause a message in the dmesg output.

====

Then try the same with the e1000 driver . reboot and then try with the modified commands:
modprobe e1000
echo "8086 10f0" > /sys/bus/pci/drivers/e1000/new_id
ifconfig -a
lscpi -nnk

then again search through the dmesg output.

*IF* either reports the interface exists, then start or restart NM anbd see if it likes it.

=======
PLZ post the exact output of any relevant lines from lspci and dmesg for additional help.
I'd particularly like to see the lspci -nnk output after either of the above.

dxbydt · #6 2009-11-03, 06:42 PM CST

Here are the dmesg lines from when the e1000e driver was installed.
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.4-k4
e1000e: Copyright (c) 1999-2008 Intel Corporation.

Here is the dmesg lines from when i tried adding the ven/dev IDs.
e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
e1000e 0000:00:19.0: setting latency timer to 64
e1000e 0000:00:19.0: irq 34 for MSI/MSI-X
0000:00:19.0: 0000:00:19.0: The NVM Checksum Is Not Valid
e1000e 0000:00:19.0: PCI INT A disabled
e1000e: probe of 0000:00:19.0 failed with error -5

Here are the dmesg lines from when the e1000 driver was installed.
Intel(R) PRO/1000 Network Driver - version 7.3.21-k3-NAPI
Copyright (c) 1999-2006 Intel Corporation.

Here are the dmesg lines from when the ven/dev IDs are added.
e1000 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
e1000 0000:00:19.0: setting latency timer to 64
e1000: 0000:00:19.0: e1000_sw_init: Unknown MAC Type
e1000 0000:00:19.0: PCI INT A disabled
e1000: probe of 0000:00:19.0 failed with error -5

Here are the lines from 'ifconfig -a'.
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1040 (1.0 KiB) TX bytes:1040 (1.0 KiB)

pan0 Link encap:Ethernet HWaddr 16:26:90:2A:76:16
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Here are the lines from 'lspci -nnk'
00:00.0 Host bridge [0600]: Intel Corporation Clarksfield/Lynnfield DMI [8086:d131] (rev 11)
Subsystem: Intel Corporation Device [8086:0000]
00:03.0 PCI bridge [0604]: Intel Corporation Clarksfield/Lynnfield PCI Express Root Port 1 [8086:d138] (rev 11)
Kernel driver in use: pcieport-driver
00:08.0 System peripheral [0880]: Intel Corporation Clarksfield/Lynnfield System Management Registers [8086:d155] (rev 11)
00:08.1 System peripheral [0880]: Intel Corporation Clarksfield/Lynnfield Semaphore and Scratchpad Registers [8086:d156] (rev 11)
00:08.2 System peripheral [0880]: Intel Corporation Clarksfield/Lynnfield System Control and Status Registers [8086:d157] (rev 11)
00:08.3 System peripheral [0880]: Intel Corporation Clarksfield/Lynnfield Miscellaneous Registers [8086:d158] (rev 11)
00:10.0 System peripheral [0880]: Intel Corporation QPI Link [8086:d150] (rev 11)
00:10.1 System peripheral [0880]: Intel Corporation QPI Routing and Protocol Registers [8086:d151] (rev 11)
00:19.0 Ethernet controller [0200]: Intel Corporation Device [8086:10f0] (rev 05)
Subsystem: Intel Corporation Device [8086:0000]
00:1a.0 USB Controller [0c03]: Intel Corporation Ibex Peak USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
Subsystem: Intel Corporation Device [8086:4257]
Kernel driver in use: ehci_hcd
00:1b.0 Audio device [0403]: Intel Corporation Ibex Peak High Definition Audio [8086:3b56] (rev 05)
Subsystem: Intel Corporation Device [8086:0034]
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation Ibex Peak PCI Express Root Port 1 [8086:3b42] (rev 05)
Kernel driver in use: pcieport-driver
00:1c.4 PCI bridge [0604]: Intel Corporation Ibex Peak PCI Express Root Port 5 [8086:3b4a] (rev 05)
Kernel driver in use: pcieport-driver
00:1c.6 PCI bridge [0604]: Intel Corporation Ibex Peak PCI Express Root Port 7 [8086:3b4e] (rev 05)
Kernel driver in use: pcieport-driver
00:1d.0 USB Controller [0c03]: Intel Corporation Ibex Peak USB2 Enhanced Host Controller [8086:3b34] (rev 05)
Subsystem: Intel Corporation Device [8086:4257]
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev a5)
00:1f.0 ISA bridge [0601]: Intel Corporation Ibex Peak LPC Interface Controller [8086:3b02] (rev 05)
Subsystem: Intel Corporation Device [8086:4257]
00:1f.2 SATA controller [0106]: Intel Corporation Ibex Peak 6 port SATA AHCI Controller [8086:3b22] (rev 05)
Subsystem: Intel Corporation Device [8086:4257]
Kernel driver in use: ahci
00:1f.3 SMBus [0c05]: Intel Corporation Ibex Peak SMBus Controller [8086:3b30] (rev 05)
Subsystem: Intel Corporation Device [8086:4257]
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 8400 GS [10de:06e4] (rev a1)
Subsystem: Micro-Star International Co., Ltd. Device [1462:1163]
Kernel modules: nouveau, nvidiafb
05:03.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) [104c:8023]
Subsystem: Intel Corporation Device [8086:4257]
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci

stevea · #7 2009-11-03, 06:49 PM CST

There is a kernel patch to support this chip.
It applies to the e1000e driver.

http://kerneltrap.org/mailarchive/li...09/6/2/5855413

These changes are included in the 2.6.31 kernel.
You'll have to install the Fedora12 (currently beta, but due out ASAP) or else bake a kernel from kernel.org source to solve your problem.

===

If you are desparate to use the 2.6.30 kernel you ould probably backport the 2.6.31 e1000e driver to 2.6.30

dxbydt · #8 2009-11-03, 06:52 PM CST

Unfortuantely this is for my corporate workstation and fedora 11 is the newest supported version. What would I have to do to apply this kernel patch? Does the patch get applied to the kernel itself? My first guess would be to get the kernel source, apply the patch, compile the kernel, and be good to go. Would that work? Thanks for the help.

stevea · #9 2009-11-04, 04:15 AM CST

Quote:

Originally Posted by dxbydt

Unfortuantely this is for my corporate workstation and fedora 11 is the newest supported version. What would I have to do to apply this kernel patch? Does the patch get applied to the kernel itself? My first guess would be to get the kernel source, apply the patch, compile the kernel, and be good to go. Would that work? Thanks for the help.

You have several realistic options.

1/ F12 is due out in 14 days. If you have access to a legacy enet card - install it, then upgrade to F12 in a few weeks. This is highly recommended.

2/ You can enable the rawhide repo (use yumex) and install kernel-2.6.31.5-96.fc12 (then disable rawhide).
This is pretty simple to do, however my concern is that all the dependency pacakges may be overwhelming.

3/ You can install th e 2.6.31 sources and just build the e1000e driver.
yum -y groupinstall "Development Tools"
yum -y install rpmdevtools kernel-devel asciidoc
rpmdev-setuptree
rpm -Uhv http://astromirror.uchicago.edu/fedo...6.fc12.src.rpm
rpmbuild -bp --target=$(arch) ~/rpmbuild/SPECS/kernel.spec

The installs the Fedora patches to 2.6.31 in the directory ~/rpmbuild/BUILD/kernel-2.6.31

To build the new driver using your current kernel includes use these commands:
cd ~/rpmbuild/BUILD/kernel-2.6.31/linux-2.6.31.i686/drivers/net/e1000e
make -C /lib/modules/$(uname -r)//build/ M=$(pwd) modules

I haven't tested, but this will probably succeed. If so then copy then
cp ./e1000e.ko /usr/lib/modules/$(uname -r)/kernel/drivers/net/e1000e/e1000e.ko
If not that you'll be forced to install the entire 2.6.31.5-96.fc12 binary package. See 2/.
--

BTW if method 2 fails, you can use grub to boot an older kernel, then uninstall the kernel-*fc12 package.
If method 3 fails you just have a different non-working e1000e.ko driver. No problem.

[added]
Method 2/ fails. More than the driver changes from 2.6.30 to 2.6.31 Some of the include files and support functios for enet change.

You'll have to install the rawhide kerne, build the rawhide kernel from scratch, or install an old enet card.

dtjohnst · #10 2009-11-19, 04:09 PM CST

I had the same problem. I wanted to install Gentoo but the drivers weren't available in their latest minimal CD yet. FC12 seems to be the only one that has them. I can now get an internet connection, but everything I download through it is corrupt. I did download the Stage 3 tarball and the portage files on another PC and transferred them with a USB stick, but after chrooting in I can't emerge a kernel because the downloads keep coming up corrupt.

Edit: For anyone else reading this using an 82578DC NIC, it was indeed the drivers on the LiveCD (I spent 3 hours doing testing and will be submitting a bug report soon). I was concerned it may have been a problem with the upstream kernel, but I have been able to get working downloads with Sabayon which also uses the 2.6.31 kernel as well as with my custom rolled Gentoo kernel. I imagine subsequent releases of Fedora won't suffer this problem so you'll have to find a work-around for now.