Why is the second PCIe network card not recognized by Linux

linux-networkingnetworking

The machine is an IBM ThinkCentre (model 8115LUA) with two PCI slots – x1 and x16 if I recall (the designations) correctly.

There are two identical network cards in these PCIe slots. Initially, the system would not start – it appeared that it was trying to use one of the network cards for a video card (with expected results) – presumably the x16 slot. The video is from the Intel 82945G Chipset.

I removed the network card in the oversize PCIe slot, set the BIOS to use on-board video only, and rebooted. Booting was good. After putting the network card back in, booting was still good.

However, only one network card is recognized (as eth1) – then gets "implemented" as eth2 (!).

[    5.148758] eth1: Tigon3 [partno(BCM95761) rev 5761100] (PCI Express) MAC address 00:10:18:80:de:36
[    5.148765] eth1: attached PHY is 5761 (10/100/1000Base-T Ethernet) (WireSpeed[1])
[    5.148771] eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    5.148776] eth1: dma_rwctrl[76180000] dma_mask[64-bit]

lspci:

00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
02:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)

The two cards in question are identical; one is seen above at 04:00.0. The networking device at 02:00.0 is the internal network device.

I get link lights on all three devices (both PCIe Gigabit cards, and internal network device), with traffic flow lights to match. Linux recognizes link loss on both eth0 and eth2 (recognized devices) but logs nothing when using unrecognized device in PCIe 16x slot.

In the BIOS, I set the active video to IGD (Integrated Graphics Device, I assume).

How do I make the second network card work? There are no other PCIe slots available in this system; just these two.

Best Answer

I know this is an old question, but I'll give it a go anyway.

This PCIe x16 slot in ThinkCentres is dual-purpose. It can be used as a PCIe x16 slot, or as an extension for the onboard graphics (adding a DVI-D port to the onboard IGP).

Often the BIOS won't properly recognize any PCIe card in that slot. (I have seen it happen with video cards, NICs, TV tuner cards.)

Solution for me has always been the following:

  1. Upgrade the BIOS to latest version first. (The shipping BIOS is usually a quite early version.) Do a reset to factory defaults after the upgrade.
  2. If that didn't fix the issue, remove the CMOS battery for 10 minutes. Put it back in. Boot and go immediately into the BIOS and reset to factory defaults. Don't let it boot without the reset! ThinkCentres in the 8xxxx series have an annoying habit of attempting to boot with trash in the CMOS in stead of a sensible default.