# [closed]lspci not showing new card

## TheLexx

I recently purchased a cheep RTL8169 card to replace my failing on-board Ethernet Controller. The problem I having now is that the card dose not even show up in lspci using Gentoo with my current kernel.  The card does however show up if a use my old EOL kernel.

The motherboard I am using had 3 types of hardware buses, 3 PCI-e x1, 1 PCI-e x16, 3 PCI. The only video interface is on the PCI-e x16.  Before purchasing the RTL8169 the PCI-e x1 was never used. To do this experiment, I added a PCI card just so that I had something to detect.  the PDC20262 is not usually present I just wanted to know if it was detected.

My first guess is that the kernel doesn't have the correct driver to access the PCI-e x1 bus, however this seems odd, because it can access the PCI-e x16 bus. I would assume that both buses use the same kernel driver.

When I upgraded to 4.9 kernel, I basically started the configuration from scratch, although I did set (to compile as module) by hand many PCI and USB devices I had used in the past. Example the PDC20262 card even though it was not present at time the kernel was compiled.

Here is the output of lspci running Gentoo using my current LTS 4.9.145 kernel

https://pastebin.com/Aw7XhH3x

Here is the output of lspci running Gentoo using my outdated 3.4.105 kernel

https://pastebin.com/DN8duv0S

edit: changed from Finnix counter-example to Kernel 3.4.105

edit: Moved lspci > pastebin.com, sorry I though long CODE block was collapsed with scroll bard. I must have been thinking of different forum.Last edited by TheLexx on Sat Nov 02, 2019 12:32 am; edited 2 times in total

----------

## mike155

Please post the kernel config of your Gentoo kernel AND (if possible) of the Finnix kernel using wgetpaste.

Which mainboard and CPU do you have?

----------

## TheLexx

Dot config file for 4.9.145 

https://pastebin.com/CW04Pjxb

Dot config file for 3.4.105

https://pastebin.com/ayErMX1A

Mother Bord: Abit kn8 Ultra

```

lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                1

On-line CPU(s) list:   0

Thread(s) per core:    1

Core(s) per socket:    1

Socket(s):             1

Vendor ID:             AuthenticAMD

CPU family:            15

Model:                 47

Stepping:              2

CPU MHz:               2009.296

BogoMIPS:              4018.59

L1d cache:             64K

L1i cache:             64K

L2 cache:              512K

```

----------

## mike155

The Abit kn8 Ultra seems to be an older mainboard from 2006 for AMD Athlon CPUs: https://www.cnet.com/products/abit-kn8-ultra-motherboard-atx-socket-939-nforce4-ultra/

Have you updated to the latest BIOS version that is available?

Are there any settings in the BIOS setup which are related to the PCI/PCIe bus? I remember that some mainboards of that time had switches that would either enable a graphics card OR one of the PCI/PCIe slots. 

I looked at your kernel config. I don't see anything terribly wrong. But options like

```
# CONFIG_AMD_IOMMU is not set

CONFIG_INTEL_IOMMU=y
```

look fishy for an AMD mainboard. 

Why are options like CONFIG_X86_POWERNOW_K8, CONFIG_X86_AMD_FREQ_SENSITIVITY or CONFIG_SENSORS_K8TEMP disabled?

Please go through your kernel .config and double-check all options that have "AMD" or "K8" in their name. 

----------

## tomtom69

It looks like the PCI descriptors of the card are faulty (could be a defective card).

Even with the old kernel where the card shows up in lspci, lspci -vk shows strange verbose  identification:

```

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev ff) (prog-if ff)

    !!! Unknown header type 7f

```

So I assume even with the old kernel the card doesn't work because the descriptors return invalid values (everything 0xff).

Can you test the card in a different PC and/or with a different OS?

----------

## Jaglover

Since the onboard NIC is also acting up it may be dying PCI bridge on that motherboard. Sometimes CMOS gets corrupted and can cause hardware malfunctioning, resetting it wouldn't hurt.

----------

## TheLexx

 *mike155 wrote:*   

> 2. Have you updated to the latest BIOS version that is available?

 

I'm not sure how to update BIOS on a system w/o Windows. It may also be ticker to find now that ABIT is defunct.

 *mike155 wrote:*   

> 3. Are there any settings in the BIOS setup which are related to the PCI/PCIe bus? I remember that some mainboards of that time had switches that would either enable a graphics card OR one of the PCI/PCIe slots.

 

Looking through the BIOS screens I did not see anything that stood out. I can look again.

 *mike155 wrote:*   

> Why are options like CONFIG_X86_POWERNOW_K8, CONFIG_X86_AMD_FREQ_SENSITIVITY or CONFIG_SENSORS_K8TEMP disabled?

 

When I configured 4.9 I could not find a good starting point, so the configuration came mainly from Linux defaults. I will look into optimizing it. I also want to run a single kernel on my Intel and AMD system.

 *tomtom69 wrote:*   

> It looks like the PCI descriptors of the card are faulty (could be a defective card). Even with the old kernel where the card shows up in lspci, lspci -vk shows strange verbose  identification:
> 
> ```
> 
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev ff) (prog-if ff)
> ...

 

It is odd how the old kernel seams to scramble the lspci data. The information that Finnix is not perfect, however the data is more complete with Finnix that it is with Gentoo. I did move the card to my Intel computer and I am able to use the card with both Gentoo 4.9 kernel and Finnix 110.

 *Jaglover wrote:*   

> Since the onboard NIC is also acting up it may be dying PCI bridge on that motherboard.

 

I would imagine that if the PCI bridge were failing I would get messages in the dmesg log. I haven't seen any. As for what is happening to my on-board NIC here is a short run-down.  For some reason the light on the Ethernet hub flashes even when the NIC is sending no data. Wireshark will show no activity. I can send data from the NIC with a high failure rate. The ping failure rate is between 5% and 65% the faster the light flashes the higher the failure rate. Even when I disable the on-board NIC in BIOS the hub light flashes.

 *Jaglover wrote:*   

> Sometimes CMOS gets corrupted and can cause hardware malfunctioning, resetting it wouldn't hurt.

 

I noticed that occasionally at boot-up, the BIOS warned me of a processor change and suggested a settings change.  The odd part was, I had not changed anything other than PCI & PCIe cards. The HW clock seamed to be loosing more than 10 minutes per year, so after reading your suggestion, I changed the 2032 battery. I then reloaded default settings then re-modified custom settings. This did not seem to effect the issue at hand.

----------

## TheLexx

After putting the NIC onto another computer I was able to determine that the card indeed functions under Finnix & Gentoo.

I'm not sure if Debugging my hardware problem in Finnix will go over well here. On my AMD system, I was able to get within striking distance of getting my card to work under Finnix, but I was not able to get it functional.  I did however get some interesting info from the dmesg log that could tell us what is happening.  Finnix 110 runs on a Debian patched 3.13 kernel, unfortunately the dot config file was not preserved.  Depending on how things go, I will post the results of Gentoo on my Intel in a later post.

The first thing I noticed when searching the dmesg was the message "r8169 0000:04:00.0: cache line size of 32 is not supported" does anyone know that the meaning of this? Here is a wider look at dmesg.

```

# grep r8169 dmesg.saved

[    4.638163] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    4.638178] r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control

[    4.652020] r8169 0000:04:00.0: Refused to change power state, currently in D3

[    4.652248] r8169 0000:04:00.0: cache line size of 32 is not supported

[    4.652252] r8169 0000:04:00.0 (unregistered net_device): Mem-Wr-Inval unavailable

[    4.652272] r8169 0000:04:00.0 (unregistered net_device): unknown MAC, using family default

[    4.662254] r8169 0000:04:00.0 (unregistered net_device): rtl_chipcmd_cond == 1 (loop: 100, delay: 100).

[    4.662443] r8169 0000:04:00.0 eth0: RTL8168b/8111b at 0xf8020000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 17

[    4.662446] r8169 0000:04:00.0 eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]

```

Even with the error, lspci was able to retrieve all the info on the NIC

```

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

   Subsystem: Realtek Semiconductor Co., Ltd. Device 0123

   Flags: fast devsel, IRQ 17

   I/O ports at 6000 [disabled] [size=256]

   Memory at fd704000 (64-bit, prefetchable) [disabled] [size=4K]

   Memory at fd700000 (64-bit, prefetchable) [disabled] [size=16K]

   Capabilities: [40] Power Management version 3

   Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+

   Capabilities: [70] Express Endpoint, MSI 01

   Capabilities: [b0] MSI-X: Enable- Count=4 Masked-

   Capabilities: [d0] Vital Product Data

   Capabilities: [100] Advanced Error Reporting

   Capabilities: [140] Virtual Channel

   Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00

   Kernel driver in use: r8169

```

Interestingly enough, when I tried to access the NIC I found that the hardware address showed up as all F's. Using the command "ifconfig hw ether ..", I was able to change the HW but I was still unable to communicate over the NIC.

I was successfully using the NIC on my Intel under Finnix. here is an excerpt from dmesg.

```

# grep r8169 dmesg.saved

[    3.617447] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    3.617460] r8169 0000:01:00.0: can't disable ASPM; OS doesn't have ASPM control

[    3.617872] r8169 0000:01:00.0: irq 49 for MSI/MSI-X

[    3.618026] r8169 0000:01:00.0 eth0: RTL8168evl/8111evl at 0xffffc90010756000, 00:e0:4c:68:11:57, XID 0c900800 IRQ 49

[    3.618029] r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    8.208958] r8169 0000:01:00.0: firmware: failed to load rtl_nic/rtl8168e-3.fw (-2)

[    8.208960] r8169 0000:01:00.0: Direct firmware load failed with error -2

[    8.208961] r8169 0000:01:00.0: Falling back to user helper

[   11.217234] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)

[   11.229993] r8169 0000:01:00.0 eth0: link down

[   11.230007] r8169 0000:01:00.0 eth0: link down

[   12.839317] r8169 0000:01:00.0 eth0: link up

```

and lspci

```

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

   Subsystem: Realtek Semiconductor Co., Ltd. Device 0123

   Flags: bus master, fast devsel, latency 0, IRQ 48

   I/O ports at dc00 [size=256]

   Memory at d0004000 (64-bit, prefetchable) [size=4K]

   Memory at d0000000 (64-bit, prefetchable) [size=16K]

   Capabilities: [40] Power Management version 3

   Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+

   Capabilities: [70] Express Endpoint, MSI 01

   Capabilities: [b0] MSI-X: Enable- Count=4 Masked-

   Capabilities: [d0] Vital Product Data

   Capabilities: [100] Advanced Error Reporting

   Capabilities: [140] Virtual Channel

   Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00

   Kernel driver in use: r8169

```

The command lspci retrieved virtually the same info for the Intel and AMD machines, however in my Intel system Finnix was able to retrieve the HW address for the NIC. The HW came up as 00:e0:4c:68:11:57, and I can get it running as soon as I set the IP using ifconfig. I also noticed that even though the dmesg says something about a failed firmware load for the NIC, the NIC operated without error.

-notes -

The complete dmesg on AMD system

https://pastebin.com/CPZZriVy

The complete lspci on AMD system

https://pastebin.com/pUfAXCmz

The complete dmesg on Intel system

https://pastebin.com/SdzjQcLM

The complete lspci on Intel system

https://pastebin.com/JFJUwruS

The Basic rundown on my Intel system is 

motherboard: Dell 0G261D

```

# lscpu 

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                2

On-line CPU(s) list:   0,1

Thread(s) per core:    1

Core(s) per socket:    2

Socket(s):             1

NUMA node(s):          1

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 23

Stepping:              10

CPU MHz:               2992.392

BogoMIPS:              5984.78

Virtualization:        VT-x

L1d cache:             32K

L1i cache:             32K

L2 cache:              6144K

NUMA node0 CPU(s):     0,1

```

----------

## krinn

 *TheLexx wrote:*   

> I'm not sure how to update BIOS on a system w/o Windows. It may also be ticker to find now that ABIT is defunct.

 

You have freedos.org to provide needed layer, other things you need should be provided by ABIT in the m/b CD, but for the latest bios, well, maybe some owner of that m/b could provide it

----------

## NeddySeagoon

TheLexx,

dmesg on the AMD says.

```
[    4.652020] r8169 0000:04:00.0: Refused to change power state, currently in D3
```

```

D3: The D3 state is further divided into D3 Hot (has auxiliary power), and D3 Cold (no power provided):

    Hot: A device can assert power management requests to transition to higher power states.

    Cold or Off has the device powered off and unresponsive to its bus.
```

It follows that the device is either totally powered off, or is some 'standby' state.

In short, while its stuck in D3, it won't work.

-- edit --

Poke at ACPI in the kernel, or can you turn it off, just for testing?

Add acpi=off to your kernel command line. Use grubs boot time editor.

This is not a fix, just a test. Its a very blunt instrument.

See /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt

----------

## krinn

 *NeddySeagoon wrote:*   

> This is not a fix, just a test. Its a very blunt instrument.

 

I would also try disable PnP/os in bios to have the bios waking up the device so it might not reach kernel in a power saving state

----------

## TheLexx

I'm going to consider this issue closed. My problem is apparently linked to BIOS and power management. My PCI bus looks to be working fine, so I ordered a PCI based RTL8169 card for under 8USD. It seems like "for now" this is the "smart choice".

In the not too distant future I will get my "other computer" into a tower case. At that point, I may switch things around and my current AMD mobo would be relegated to "the computer to just test stuff out on".  When this happens, I may want to open this issue up again so that I can test PCIe HW on it. Until then, I don't want to contently reboot my AMD mobo computer.

PS. I know that my config is a bit odd for a kernel running on an AMD mobo, however I ran some distros with "generic run on anything" kernels and I still had problems when playing around with "acpi=off" and similar acpi commands. If/when I reopen this issue, I'll upgrade the BIOS and I will discuss the details.

----------

