# [Solved] ethernet adapter not detected

## jyoung

Hi Folks,

I have exactly the same system on two *nearly* identical computers, but on just one it won't detect the ethernet adapter. On the non-working computer, ifconfig -a does not return anything. Both computers have an  Intel I219-V, which, as far as I can tell, runs off the e1000e driver. This driver is compiled into the kernel. Both computers are Dell OptiPlex 5040's. The only hardware differences are revealed by lscpi. On the working computer lspci returns:

```
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07)

00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)

00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)

00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)

00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)

00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT Redirection (rev 31)

00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode] (rev 31)

00:1b.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Root Port #17 (rev f1)

00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)

00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)

00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)

00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V (rev 31)

02:00.0 Non-Volatile memory controller: Toshiba America Info Systems Device 0115 (rev 01)
```

And on the non-working computer:

```
00:00.0 Host bridge: Intel Corporation Device 591f (rev 05)

00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 05)

00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev 04)

00:14.0 USB controller: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller

00:14.2 Signal processing controller: Intel Corporation 200 Series PCH Thermal Subsystem

00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1

00:16.3 Serial controller: Intel Corporation Device a2bd

00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode]

00:1f.0 ISA bridge: Intel Corporation 200 Series PCH LPC Controller (Q270)

00:1f.2 Memory controller: Intel Corporation 200 Series PCH PMC

00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio

00:1f.4 SMBus: Intel Corporation 200 Series PCH SMBus Controller

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (5) I219-V
```

These differences notwithstanding, I'm perplexed as to what's going on. Any ideas?

Code tags added by NeddySeagoonLast edited by jyoung on Mon Jun 11, 2018 5:03 am; edited 1 time in total

----------

## NeddySeagoon

jyoung,

One is Sunrise Point. If you don't have the Sunrise Point drivers in the kernel, almost nothing works.

The non working has a 

```
Intel Corporation 200 Series PCH SMBus Controller
```

Is its driver loaded?

----------

## jyoung

I just enabled the sunrisepoint driver and tried again, with no effect.

----------

## NeddySeagoon

jyoung,

We miscommunicated. You need the driver for 

```
Intel Corporation 200 Series PCH SMBus Controller
```

in the not working system.

While those two systems may have the same vendor sticky label, they are quite different on the inside.

Boot the non working one with a random live distro, System Rescue CD is recommended, and run 

```
lspci -k
```

That will tell the hardware drivers in use.

----------

## jyoung

Okay, it looks like we have our driver:

```
00:1f.4 SMBus: Intel Corporation 200 Series PCH SMBus Controller

        Subsystem: Dell 200 Series PCH SMBus Controller

        Kernel driver in use: i801_smbus
```

However, it's not clear which kernel option will enable this. Searching in '801' menuconfig returns I2C_SMBUS and I2C_I801. But, that those options were already enabled on the non-working machine.

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## NeddySeagoon

jyoung,

Please put your kernel .config file onto a pastebin site.

The output of dmesg will be good too.

Tell us how you configured and built your kernel.

----------

## jyoung

Okay, I've just posted it:

https://pastebin.com/wJYzKUW7

I configured my kernel manually, following the gentoo handbook. I'm not sure this matters, but this is kind of a weird setup in that it's installed on a external USB drive.

The kernel is kind of old, 4.4.6.

[Moderator edit: fixed URLs.  Auto-linking requires you to specify the protocol.  If you omit the protocol, readers must copy&paste the domain+path and guess a protocol -Hu]

----------

## NeddySeagoon

jyoung,

Your kernel .config looks mostly harmless.

Turning on options with DEBUG in their names is usually a bad thing.

Effects vary from mild cases of logspam to making the affected driver unusable. 

```
CONFIG_I2C_DEBUG_CORE=y

CONFIG_I2C_DEBUG_ALGO=y

CONFIG_I2C_DEBUG_BUS=y

CONFIG_DEBUG_PINCTRL=y
```

Those options may impact your system management bus performance. 

```
CONFIG_USB_STORAGE_DEBUG=y
```

will cripple your USB storage throughput as it prints the details of every USB transaction to the kernel log.

There are a few useful low overhead debug options, mostly around CONFIG_PRINTK_TIME.

Random thought.

```
CONFIG_NTFS_RW=y
```

turn that off. Kernel NTFS write support is limited to changing the content or an existing file, provided the file size does not change.

It used to trash your filesystem but its safe now. Use kernel CONFIG_FUSE_FS=y and emerge sys-fs/ntfs3g instead.

All the debug logspam will make your dmesg useless. Fix your kernel debug options then post your revised kernel .config and the output of dmesg.

Having the install on USB only impacts getting the root filesystem mounted. After that, its not special.

----------

## jyoung

Okay,  here's the updated kernel:

https://pastebin.com/kuR4CGwV

and here's the dmesg:

https://pastebin.com/RQ5cq53W

[Moderator edit: fixed URLs.  Auto-linking requires you to specify the protocol.  If you omit the protocol, readers must copy&paste the domain+path and guess a protocol -Hu]

----------

## hhfeuer

The working system is a Skylake, the non-working a Kabylake. Kernel 4.4 is much too old for it. Kabylake requires a minimum of kernel 4.8.

So both system are Intel systems, that's all they have in common.

Edit: coming to think of it, even for a Skylake to fully work (regarding i915 driver/firmware) kernel 4.4 is too old.

----------

## jyoung

Ah, makes sense. I'll upgrade to a newer kernel and report back.

----------

## jyoung

Hi Folks,

The new 4.17.0 kernel did the trick. Thanks everyone!

Also, the tip about 

```
CONFIG_USB_STORAGE_DEBUG
```

explains why the log files were getting so large; I appreciate that was well.

----------

