I recently bought some new hardware and am running into issues getting Ethernet to work, as no combination of kernels and drivers I've tried is working. I've hypothesized the issue is either faulty hardware, or poor device support (due to how recently its been released). But given what I've tried below, I'm wondering what would be good next steps to resolve the issue.
Trial and Error:
I've tried (unsuccessfully) with the following combination of kernels and driver versions:
- Debian 10.7 (Buster), Kernel 4.19, kernel e1000e
- Debian 10.7 (Buster), Kernel 4.19, compiled e1000e 3.8.4
- Debian 10.7 (Buster), Kernel 4.19, compiled e1000e 3.8.7
- Arch Linux LiveUSB, Kernel 5.9, kernel e1000e
Using the 2020-12-01 Arch Linux installation medium, I get the following diagnostic output from
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Linux archiso 5.9.11-arch2-1 #1 SMP PREEMPT Sat, 28 Nov 2020 02:07:22 +0000 x86_64 GNU/Linux
00:00.0 Host bridge : Intel Corporation Device [8086:9b63] (rev 03) 00:01.0 PCI bridge : Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 03) 00:02.0 VGA compatible controller : Intel Corporation Device [8086:9bc8] (rev 03) 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a3af] 00:14.2 Signal processing controller : Intel Corporation Device [8086:a3b1] 00:16.0 Communication controller : Intel Corporation Device [8086:a3ba] 00:17.0 SATA controller : Intel Corporation Device [8086:a382] 00:1b.0 PCI bridge : Intel Corporation Device [8086:a3e9] (rev f0) 00:1b.4 PCI bridge : Intel Corporation Device [8086:a3eb] (rev f0) 00:1c.0 PCI bridge : Intel Corporation Device [8086:a394] (rev f0) 00:1d.0 PCI bridge : Intel Corporation Device [8086:a398] (rev f0) 00:1f.0 ISA bridge : Intel Corporation Device [8086:a3c8] 00:1f.2 Memory controller : Intel Corporation Device [8086:a3a1] 00:1f.3 Audio device : Intel Corporation Device [8086:a3f0] 00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a3a3] 00:1f.6 Ethernet controller : Intel Corporation Ethernet Connection (12) I219-V [8086:0d55] 01:00.0 Serial Attached SCSI controller : Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) 02:00.0 PCI bridge : Integrated Technology Express, Inc. IT8892E PCIe to PCI Bridge [1283:8892] (rev 41)
Kernel 4.19 doesn't seem to support my ethernet chipset (device code 0d55), which seems to only be supported in 5.5 and later. So it makes sense not to be supported in my stock Debian Buster install, but it doesn't make sense that the self-compiled 3.8.4/3.8.7 e1000e drivers are still broken, as my chipset should have been supported since version 3.5.1
dmesg | grep e1000e
[ 7.373433] e1000e: Intel(R) PRO/1000 Network Driver [ 7.373434] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 7.373684] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 7.749973] e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): Failed to disable ULP [ 8.340480] e1000e: probe of 0000:00:1f.6 failed with error -2
Notice the PCI address
0000:00:1f.6, which corresponds to the integrated I219-V chipset from the
The ULP error appears in the Arch Linux liveUSB, but it doesn't appear in my Debian Stable tests. However, the probe error still does. An error of -2 corresponds to
-E1000_ERR_PHY, which some people report has the following solutions:
- Disable wake-from-LAN
- Unplug from power and wait anywhere from a few hours to a day and try again
- Do not plug in Ethernet until after interface comes online
I've tried these to no avail. It's been suggested by friends on IRC that the ULP (ultra low power) error might indicate the card is constantly stuck in ULP mode, which is why attempting to probe the device fails with a PHY error.
One suggested that this mailing list thread might be relevant, but I'm not sure if attempting to grab their commit source code and applying all the relevant patches myself would be helpful. If someone insists it would, I am happy to try.
UPDATE 1: A friend had the smart idea of trying a fresh Windows install to help diagnose whether it's a hardware issue. After installing Windows 10 and using the provided motherboard driver bundle, the card is recognized but the Windows Device Manager gives a "Device cannot start (Code 10)" error. (I think at this point it's clear it's not a *nix-specific issue, so I should close the question and contact Gigabyte/Intel directly, or ask someone to move this post to the Superuser site.)