Intel DP55WB NIC not detected

elfoozo · 09-26-2009, 10:45 AM

Using Debian lenny amd64. The onboard NIC isn't detected during installation. Intel's Windows driver download page lists this NIC in the same download as the DX38BT. I've been using a DX38BT without issue for about a year.

Is it likely the DP55WB NIC is different?

Or does anyone have a suggestion to help discover the card?

Drakeo · 10-01-2009, 08:51 AM

open at terminal and as root type lspci post it this is your board specs

Quote:

http://downloadmirror.intel.com/1813...chProdSpec.pdf

Your board has Pci express chip so you need to go into bios and set it to be used. your bios are different then mine but I ran in to the same problem thought it was linux but it was bios. You see windows runs bios linux just reads them. so in bios you are just enabling the device to connect.
this blew my mind when I got mine. Because I went into bios and enabled the device. but you must also allow the device to be used at boot up. then while your in bios set the bios to none O/S or non windows.
reboot all should be well.

Quote:

please post your lspci and your dmesg

this is part of the pci express controller chip. this is for people in offices that boot from the network. so you can enable the device but it still does not work so you must enable connecting to a network or what ever option in bios are.
and also

Quote:

if bios do not read it it will not be loaded. if bios does not allow connection it will not work.

elfoozo · 10-01-2009, 12:28 PM

Quote:

Originally Posted by Drakeo

open at terminal and as root type lspci post it this is your board specs

This hosts lspci output:

Code:

00:00.0 Host bridge: Intel Corporation Clarksfield/Lynnfield DMI (rev 11)
00:03.0 PCI bridge: Intel Corporation Clarksfield/Lynnfield PCI Express Root Port 1 (rev 11)
00:08.0 System peripheral: Intel Corporation Clarksfield/Lynnfield System Management Registers (rev 11)
00:08.1 System peripheral: Intel Corporation Clarksfield/Lynnfield Semaphore and Scratchpad Registers (rev 11)
00:08.2 System peripheral: Intel Corporation Clarksfield/Lynnfield System Control and Status Registers (rev 11)
00:08.3 System peripheral: Intel Corporation Clarksfield/Lynnfield Miscellaneous Registers (rev 11)
00:10.0 System peripheral: Intel Corporation QPI Link (rev 11)
00:10.1 System peripheral: Intel Corporation QPI Routing and Protocol Registers (rev 11)
00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 05)
00:1a.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation Ibex Peak High Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 1 (rev 05)
00:1c.4 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 5 (rev 05)
00:1c.6 PCI bridge: Intel Corporation Ibex Peak PCI Express Root Port 7 (rev 05)
00:1d.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Ibex Peak LPC Interface Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation Ibex Peak 6 port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation Ibex Peak SMBus Controller (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9400 GT] (rev a1)
05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Quote:

Originally Posted by Drakeo

and your dmesg

Output from dmesg:

Code:

removed - output makes post exceed 30000 characters.

Quote:

Originally Posted by Drakeo

Your board has Pci express chip so you need to go into bios and set it to be used.

Entries from this BIOS:

Code:

F2 -->
   Configuration -->
                 On-board LAN <Enable>
   Boot -->
        Boot to Network <Enable>

Quote:

Originally Posted by Drakeo

your bios are different then mine but I ran in to the same problem thought it was linux but it was bios. You see windows runs bios linux just reads them. so in bios you are just enabling the device to connect.

Mine has already been enabled since starting this journey.

Quote:

Originally Posted by Drakeo

this blew my mind when I got mine. Because I went into bios and enabled the device. but you must also allow the device to be used at boot up. then while your in bios set the bios to none O/S or non windows.
reboot all should be well.

There does not appear to be an option to choose OS in this BIOS

Drakeo · 10-02-2009, 05:32 AM

According to your lspci you device is seen and the drivers loaded.

Quote:

00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 05)

and

Quote:

05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

as sudo or root type ifconfig and look for you eth0 if not ifconfig eth0 up then type ifconfig.
let me know.

elfoozo · 10-02-2009, 07:01 AM

Quote:

Originally Posted by Drakeo

According to your lspci you device is seen and the drivers loaded.

00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 05)

The above is the onboard Intel NIC that was not detected during install.

Quote:

Originally Posted by Drakeo

05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

This is a 2nd PCI NIC I inserted to get around having no network while the installer ran.

Quote:

Originally Posted by Drakeo

as sudo or root type ifconfig and look for you eth0 if not ifconfig eth0 up then type ifconfig.
let me know.

Code:

ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:50:ba:44:1b:6e
          inet addr:192.168.0.57  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::250:baff:fe44:1b6e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13456 (13.1 KiB)  TX bytes:12179 (11.8 KiB)
          Interrupt:22 Base address:0x2000

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:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:480 (480.0 B)  TX bytes:480 (480.0 B)

In the above output, eth0 is the 2nd NIC. The onboard Intel NIC has no entry.

Here's what udev contains:

Code:

cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:ba:44:1b:6e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Drakeo · 10-03-2009, 11:29 AM

ifconfig eth1 up try that. you realize the . I have the same nic onboard as you and this is what my kernel read out is.

Quote:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

this is 2.6.29.6 kernel. if you are using the original kernel for lenny 2.6.18 your right it will not detect it till the 2.6.25 kernel.
hang in there.

elfoozo · 10-04-2009, 09:58 AM

Quote:

Originally Posted by Drakeo

ifconfig eth1 up try that. you realize the . I have the same nic onboard as you and this is what my kernel read out is. this is 2.6.29.6 kernel. if you are using the original kernel for lenny 2.6.18 your right it will not detect it till the 2.6.25 kernel.
hang in there.

I used a daily build of debian net install. Daily used kernel 2.6.30 and didn't pick up the Intel NIC. That was why I inserted a 2nd NIC which became eth0 and is getting me by for now. Thanks for your suggestions!

allaboutmike · 10-27-2009, 01:14 AM

Quote:

Originally Posted by Drakeo

According to your lspci you device is seen and the drivers loaded. and
as sudo or root type ifconfig and look for you eth0 if not ifconfig eth0 up then type ifconfig.
let me know.

Just in case anyone is still reading this thread:
lspci does not say anything about whether the kernel detects a given piece of hardware, or whether a driver is loaded for it. PCI cards have a little ROM or some such in them that stores a manufacturer/hardware id pair. lspci reads this and with the help of a list (which you can update on many distros using update-pciids) shows the human readable form which has the manufacturer and model description written out for us to read. This is completely independent of your kernel having/lacking support and drivers/modules being loaded or not.
Mike

elfoozo · 10-27-2009, 07:41 AM

I still read this thread and updated the lspci database. The NIC still isn't detected by default in a stock 2.6.30-2-amd64 debian kernel. I have not taken the effort to recompile though.

allaboutmike · 10-27-2009, 11:16 AM

elfoozo, I have not made myself clear enough. lspci is a utility which directly reads manufacturer and model id numbers from the pci devices in question. All it can do is read these numbers and lookup the name and model information in its database of devices. (It can also tell you a lot of technical detail on other aspects of the device; like interrupts, memory addresses, timings etc) lspci is a useful tool to find out what it is that you have installed in your computer, but it has no part in the kernel actually using these devices. Updating the pciids database simply offers more up to date human readable data, which will help you identify new cards (which would otherwise only show as numbers).
The drivers for nics (and other devices) are either compiled into the kernel or loaded in modules at runtime. These drivers will use the manufacturer and model id numbers to identify existing hardware in your machine and thereby know if they are responsible for controlling that device. This card's id numbers do not appear in the code of any driver in your (or my) kernel version and so are not claimed by any driver and are not able to be used by us.
Sometimes it happens that a new revision is similar enough to an older card, that the driver authors can just add its pci id numbers to an existing driver and it may work. At other times, there are differences small or large that require alterations in the code, or even entirely new drivers. I haven't got far enough into this yet to determine which is the case for this nic.
On a positive note, I have read that as of 2.6.31, the 82578DC is detected by the kernel. I'm going to download that kernel when I get back to the machine (Friday I think) and hopefully it will go well. Good luck, it should be a good platform!
Mike

elfoozo · 10-27-2009, 11:47 AM

Actually, you were clear enough for me. I grasped your intent from your first response and am familiar enough with lspci, lsmod, kernel recompiles, etc. to know where you were headed.

I probably should have been more verbose that a) I updated my lspci data set, just because, and b) after a few weeks going by with me updating the OS regularly using 'unstable', a stock kernel + loadable modules does not yet pick up that NIC dynamically. Then lastly, but separately, I have not taken the time to recompile a customized kernel to see if that NIC support can be "compiled in".

allaboutmike · 10-27-2009, 11:10 PM

Indeed, I misunderstood your shortened version.
I have just resync'd my portage repositry (I love Gentoo) and the latest kernel in the stable tree is 2.6.30-gentoo-r8 and in the unstable tree 2.6.31-gentoo-r4 so it looks like I will be able to test on Friday. I'll post back if successfull. What kernel version have you got up to?
Mike

elfoozo · 10-28-2009, 12:28 AM

Here's what is running at the moment:

Code:

localhost:~# aptitude show linux-image-`uname -r`
Package: linux-image-2.6.30-2-amd64
New: yes
State: installed
Automatically installed: yes
Version: 2.6.30-8
Priority: optional
Section: kernel
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Uncompressed Size: 88.1M
Depends: module-init-tools, initramfs-tools (>= 0.55) | yaird (>= 0.0.13) | linux-initramfs-tool
PreDepends: debconf | debconf-2.0
Suggests: linux-doc-2.6.30, grub | lilo
Conflicts: initramfs-tools (< 0.55), yaird (< 0.0.13)
Provides: linux-image, linux-image-2.6, linux-modules-2.6.30-2-amd64
Description: Linux 2.6.30 image on AMD64
 This package provides the binary image and pre-built loadable modules for Linux kernel 2.6.30 on all 64bit single- and multiprocessor AMD and Intel machines.

Here mentions a patch:
http://kerneltrap.org/mailarchive/li...09/6/2/5855413
but I've not worked with patching before.

allaboutmike · 10-29-2009, 01:49 AM

The patch seems to be adding the pciids and a bit of extra code for new features to the existing e1000 driver. It certainly seems like what we are looking for from my initial reading.
I don't know specifically how to patch the kernel under ubuntu, but I imagine there is a kernel development package that you have to install to get the source code. Once there, the patch is usually applied against a "vanilla" kernel without drama, so unless the ubuntu one is already heavily patched you should be OK. The patch in question seems to only affect a few files (e1000.*).
Once the source is patched, you would compile and install the kernel, reboot and cross your fingers.
If none of that made sense or is beyond your experience, you are probably better off waiting for a 2.6.31 binary kernel package to be released. I'm sure I read somewhere that these cards are supported in that kernel version.
I'll be trying out 2.6.31 tomorrow. I'll let you know.
Mike

elfoozo · 11-17-2009, 03:50 PM

I did a dist-upgrade today and the kernel+driver is updated for this NIC.
I removed the temporary NIC, modified my udev persistent net to reflect the right eth0 and all seems well.