Intel I226-V (M.2 A+E) disappears on kernel 7.0.14-4, works on 6.17.2-1 (Lenovo M710q Tiny)

K

kamukamo19

New Member
Jul 7, 2026
3
0
1
Hi everyone,

I'm encountering what appears to be a kernel regression affecting an Intel I226-V NIC (m.2 A+E Card) installed in a Lenovo ThinkCentre M710q Tiny.

Hardware
Proxmox VE 9 (pve-no-subscription repository)
Lenovo ThinkCentre M710q Tiny
BIOS: M1AKT5A0 (03/10/2025)
Intel I226-V (M.2 A+E Key adapter)
Management interface connected at 2.5 Gbps

Working kernel
6.17.2-1-pve

Everything works correctly.

uname -r
6.17.2-1-pve

ethtool -i nic0

driver: igc
version: 6.17.2-1-pve
firmware-version: 2017:888d
bus-info: 0000:02:00.0

ethtool nic0

Speed: 2500Mb/s
Duplex: Full
Link detected: yes

The NIC is visible in lspci:

02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)

Problematic kernel
7.0.14-4-pve

After booting this kernel:

Kernel oops occurs in igc_watchdog_task
Local console login hangs after authentication
The I226-V disappears completely
lspci only shows the onboard Intel I219-LM
lsmod | grep igc returns nothing

The kernel command line currently includes:

pcie_aspm.policy=performance pcie_port_pm=off

Those parameters did not change the behavior.

Additional observation

If I boot 7.0.14-4, the I226-V remains missing even after warm rebooting back into 6.17.2-1.

Only after:

Shutting the system completely down
Removing AC power
Waiting a few seconds
Reconnecting power

does the I226-V reappear when booting 6.17.2-1.

This makes me think the newer kernel leaves the device in a bad state that survives warm reboot.

Things already tested
Different Ethernet cable
Verified switch and link
Added:
pcie_aspm.policy=performance
pcie_port_pm=off
Confirmed ASPM is already reported as disabled by lspci -vv
Cold boot vs warm reboot comparison
The adapter consistently works on 6.17.2-1

Questions
Has anyone seen a similar regression with Intel I226-V on the 7.0.x kernels?
Is this a known igc regression?
Are there any additional kernel parameters or debugging steps I should try before filing a bug report?

Thanks in advance.
 
Please share this when the NIC is missing
Bash: 
lspci -vnnk | awk '/Ethernet/{print $0}' RS=
journalctl -g "igc|02:00"
journalctl -krp warning
 
Try adding some kernel parameters -- disabling aspm and disabling the pcie power power management, these sometimes fix pcie errors on intel nics:
pcie_aspm=off pcie_port_pm=off
 
Last edited:
ggoller said:
Try adding some kernel parameters -- disabling aspm and disabling the pcie power power management, these sometimes fix pcie errors on intel nics:
pcie_aspm=off pcie_port_pm=off
Click to expand...
already tried this and some other workaround to no avail. im currently staying at 6.17.2-1.
 
Hi, I have the same issue here with two Lenovo thinkcentre M920S. Interestingly I had the issue initially on an M920T as well but that works now, I have no idea, why (the kernel version is the same on all three: Linux pve3 7.0.14-6-pve). The Link on the i226V is up and still it is not detected by the operating system (dmesg | grep -i idc shows nothing):

root@pve2:~# dmesg | grep -i igc
[ 23.540763] igc 0000:03:00.0 enp3s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[ 23.608644] igc 0000:03:00.0 enp3s0: entered allmulticast mode
[ 23.608666] igc 0000:03:00.0 enp3s0: entered promiscuous mode
[ 348.336725] igc 0000:03:00.0 enp3s0: left allmulticast mode
[ 348.336757] igc 0000:03:00.0 enp3s0: left promiscuous mode
[ 352.272197] igc 0000:03:00.0 enp3s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[ 405.799735] igc 0000:03:00.0 enp3s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[75794.873304] igc 0000:03:00.0 enp3s0: entered promiscuous mode
[75794.873433] igc 0000:03:00.0 enp3s0: entered allmulticast mode
[75839.906311] igc 0000:03:00.0 enp3s0: left promiscuous mode
[75839.906454] igc 0000:03:00.0 enp3s0: left allmulticast mode

root@pve1:~# dmesg | grep -i igc
root@pve1:~#

The trouble is that when the server reboots, the order of the network interfaces is changed, enp4s0f1 becomes enp3s0f1. Bildschirmfoto 2026-07-31 um 07.07.29.png

Apparently the bridge cannot handle disappearing interfaces, so despite having eno1 as backup in this case, the whole bridge goes down - and with it access to Proxmox. I had this yesterday night with one machine and this night with the other two. I understand that vanishing interfaces are not common but it defeats the purpose of having redundant interfaces on a bridge if it goes down anyway when the default interface is not found.
I now have a backup with an additional IP address, so I can fix this but without this, the proxmox server has no connection, so you have to fix the issue manually on the console by editing the interfaces file.

The same thing happens, when a NIC card is added, by the way, then the interfaces are renamed as well and the bridge goes down because it does not find the preferred interface. Maybe this is something you should handle in future versions.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back