E1000e kernel driver not in use, looking for better solution

User Support General
1

Hi all,

I encountered a problem on a laptop I installed Qubes OS on. I used Qubes before on a different laptop before for a year or so, so I am a bit experienced. However, the kernel stuff is a bit too much for me to fully understand.

So what happened is that everything seemed to work fine, except for the ethernet driver not loading ok. As a result, the network manager said no network devices were found, while the cable was connected ok.

Turns out some other folks ran into similar problems [1] [2]

Running lspci -v in sys-net gave for my network devices

00:06.0 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
	Subsystem: Intel Corporation Device 4030
	Physical Slot: 6
	Flags: bus master, fast devsel, latency 0, IRQ 70
	Memory at f2030000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

00:07.0 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-LM (rev 30)
	Subsystem: Dell Device 08b9
	Physical Slot: 7
	Flags: bus master, fast devsel, latency 64, IRQ 68
	Memory at f2000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel modules: e1000e

Tried to compile from Intel’s page but that referred to 3.8.4 driver, which wouldn’t compile. Fix for that was getting a more recent driver from sourceforge (version 3.8.7) which compiled ok.
My quick fix was to make a standalone sys-net (based on fedora 34) and sudo make install that latest driver (hooray! It works!)

lspci -v now returns

00:06.0 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
	Subsystem: Intel Corporation Device 4030
	Physical Slot: 6
	Flags: bus master, fast devsel, latency 0, IRQ 70
	Memory at f2030000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

00:07.0 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-LM (rev 30)
	Subsystem: Dell Device 08b9
	Physical Slot: 7
	Flags: bus master, fast devsel, latency 64, IRQ 68
	Memory at f2000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: e1000e
	Kernel modules: e1000e

So what is the problem then you might ask? I think making a standalone sys-net is not a neat way to fix this issue. I could of course build the driver in the fedora template, but I feel that goes a bit against the principle of only installing from trusted parties there.

I feel a cleaner solution for this should exist, given Sven’s comment in [qubes-users] HCL -ASRock B560 Pro (NIC Intel I219-V unrecognised), where he mentioned many people have this NIC but not many people are encountering problems.

I’ve also considered the problem may be that the kernel version, I think that is confirmed by discussion here. Could that be the case?

My software version’s are:
xen_version : 4.14.3
Linux 5.14.15-1.fc32.qubes.x86_64
kernel: 5.10.90-1.fc32

2

HI @Eleanorrais ,

I’m using an I-219 ethernet card, in sys-net:

$ lspci | grep -i ethernet
00:06.0 Ethernet controller: Intel Corporation Ethernet Connection (10) I219-V
$ lspci -vv -s 00:06.0
00:06.0 Ethernet controller: Intel Corporation Ethernet Connection (10) I219-V
	Subsystem: Intel Corporation Ethernet Connection (10) I219-V
	Physical Slot: 6
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64
	Interrupt: pin A routed to IRQ 69
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: e1000e
	Kernel modules: e1000e
$ uname -r
5.10.76-1.fc32.qubes.x86_64

But as you see it’s an I219-V, not an I219-LM.

In your case, what I will do:

  1. backup sys-net (If you break it…) with Backup Qubes tool or a clone
  2. If ethernet is mandatory, first I will use your workaround or an USB ethernet card, which give you time to solve the original issue
  3. check the kernel messages (sudo dmesg -Tw), the module informations (sudo modinfo e1000e)
  4. find the mininal required kernel version from the user feedbacks for your laptop (or near) on linux-hardware.org by providing the Vendor ID/Device ID (available for you with lspci -vv -n -s 00:07.0 | grep Subsystem)
  5. install the wanted kernel from QubesOS repositories (check the kernel latest packages for example, use the testing-repositories, read managing-vm-kernels), I see that the latest available is kernel-latest-qubes-vm-5.15.14-1.fc32.qubes.x86_64.rpm
  6. Maybe install the latest firmware-linux package (in general the kernel module log says if the kernel can’t find the good firmware).

I hope this help you…

2 Likes
3

Thanks a lot! I will have a go with this and post the results!

4

Before I begin, would I install the kernel in the template that I use for sys-net? If so, would it be better to make a seperate sys-net-t template for the purpose of not installing that kernel in the template I use in other AppVMs? Or go for a standaloneVM for sys-net?
I assume that installing the kernel in a regular AppVM would be volatile and gone on reboot, right?

I have no idea what the security or performance implications would be of installing the kernel in template in general, or diverging with another template, or keeping in standalone all together. So if you would have any ideas about this whatsoever, please share :slight_smile:

5

No the VM kernels are in dom0, see [dom0]$ rpm -qa kernel-qubes-vm. Only the 3-last kernel packages kept (by the installonly_limit=3 in /etc/dnf/dnf.conf).

Backup: you clone the template and the AppVM, and you work only with the clones (but as seen above, the kernel is in dom0). In the sys-net-cloned settings, you change the kernel from the kernel list.

Do the actions only if you understand what you do, I don’t want that you break your Qubes-OS dom0. Alternative: you wait the stable kernel updates from qubes-update. As you see on updates-status, the last stable kernel is 5.10.76 and the last latest is 5.14.15. The newer kernels are available in the testing repositories.

2 Likes
6

For reference, I had the same issue again when installing latest stable qubes (4.1.2). However, all that was needed to fix the issue this time was to go to sys-net qube settings > devices > configure strict reset for PCI devices and double click my ethernet PCI device.