Intel I225-V igc NETDEV WATCHDOG/reset loop on 7.0 kernels; stable on 6.17

[cbuechler]

I’m seeing a repeatable regression with an Intel I225-V NIC on Proxmox VE 9.2.5 which completely breaks the NIC.

The affected interface is one port of a quad-port 2.5 GbE card:

85:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03)
Subsystem: Intel Corporation Device [8086:0000]
Kernel driver in use: igc

The interface is enp133s0, attached to Linux bridge vmbr8.

With both tested 7.0 kernels, the interface repeatedly hits a transmit watchdog timeout, dumps registers, resets the adapter, renegotiates at 2.5 Gb/s, and then repeats the cycle endlessly, leaving the NIC non-functional.

Tested broken kernels:
7.0.2-4-pve
7.0.14-8-pve

Working kernel:
6.17.13-21-pve

The failure appears immediately after boot with either 7.0 kernel. Booting the same host, hardware, configuration, cable, and switch port on 6.17.13-21-pve has been stable.

Example from 7.0.14-8-pve:
igc 0000:85:00.0 enp133s0: NETDEV WATCHDOG: CPU: 12: transmit queue 1 timed out 5435 ms
igc 0000:85:00.0 enp133s0: Register Dump
igc 0000:85:00.0 enp133s0: Register Name Value
igc 0000:85:00.0 enp133s0: CTRL 581c0641
igc 0000:85:00.0 enp133s0: STATUS 40680683
igc 0000:85:00.0 enp133s0: CTRL_EXT 100000c0
igc 0000:85:00.0 enp133s0: MDIC 181e878d
igc 0000:85:00.0 enp133s0: ICR 00000085
igc 0000:85:00.0 enp133s0: RCTL 0440803a
igc 0000:85:00.0 enp133s0: RDLEN[0-3] 00001000 00001000 00001000 00001000
igc 0000:85:00.0 enp133s0: RDH[0-3] 00000002 00000000 00000000 000000fa
igc 0000:85:00.0 enp133s0: RDT[0-3] 000000ff 000000ff 000000ff 000000ff
igc 0000:85:00.0 enp133s0: RXDCTL[0-3] 02040808 02040808 02040808 02040808
igc 0000:85:00.0 enp133s0: TCTL a503f0fa
igc 0000:85:00.0 enp133s0: TDLEN[0-3] 00001000 00001000 00001000 00001000
igc 0000:85:00.0 enp133s0: TDH[0-3] 00000001 00000001 00000000 00000000
igc 0000:85:00.0 enp133s0: TDT[0-3] 00000001 00000001 00000000 00000000
igc 0000:85:00.0 enp133s0: TXDCTL[0-3] 02100108 02100108 02100108 02100108
igc 0000:85:00.0 enp133s0: Reset adapter

The full repeating sequence includes:
NETDEV WATCHDOG
Register Dump
Reset adapter
vmbr8 port entered disabled state
NIC Link is Up 2500 Mbps Full Duplex
vmbr8 port entered forwarding state

This repeats approximately every 10 seconds once it starts.

On an earlier 7.0 boot, ethtool -S enp133s0 showed:
tx_timeout_count: 278513
rx_crc_errors: 0
tx_carrier_errors: 0
rx_align_errors: 0
collisions: 0

This appears to be a driver-triggered reset loop rather than ordinary PHY link flapping.

PCIe information:
LnkCap: Speed 5GT/s, Width x1, ASPM L1
LnkCtl: ASPM Disabled
LnkSta: Speed 5GT/s, Width x1

The PCIe AER status was clean, with no correctable or uncorrectable errors recorded.

NIC driver/firmware information from the original 7.0 boot:
driver: igc
version: 7.0.2-4-pve
firmware-version: 1089:878d
bus-info: 0000:85:00.0

The interface uses the normal default offload configuration, including TSO, GSO, scatter-gather, and TX checksum offload.

Because ASPM is already disabled and the identical configuration works immediately after booting 6.17, I have not yet changed offloads, queue counts, cabling, or switch configuration. At this point the kernel comparison seems to be the cleanest indication of a regression.

Current workaround: Boot and pin 6.17.13-21-pve and it's perfectly stable.

Has anyone else seen this specifically with I225-V/I226 and the Proxmox 7.0 kernel series? I can provide complete journalctl -k logs, lspci -vv, ethtool output, or test candidate kernels/patches.

 

[Francois Baillargeon]

That smells like this https://bugzilla.proxmox.com/show_bug.cgi?id=6273

Unfortunately it required a Kernel regression

 

[cbuechler]

Thanks for the reply. That one certainly has a similar symptom, though that was reported as a 6.8 kernel regression. This seems like a separate problem with a similar symptom, since it works perfectly in 6.17 and regressed in 7.0 kernel. This system actually started its life on a 6.8 kernel version of Proxmox, and it was stable back then as well. Only once going to the 7.0 kernel does it stop working.

 

[Francois Baillargeon]

I think it may be kernel related sadly then

 

[huemic]

Re: your question about I226 – a data point on kernel 7.0.14-25-pve with an onboard i226-V (Intel NUC 14 Pro), no watchdog/reset in 40 h, but WITH workaround:

Data point: kernel 7.0.14-25-pve on Intel NUC 14 Pro (i226-V) – 40 h without igc hang/reset, but WITH workaround

Hardware: Intel NUC 14 Pro, Core 3 100U, onboard i226-V (igc), PCIe x1 5 GT/s, link 2500 Mbps full duplex, bridged (vmbr0, VLAN-aware).
PVE: pve-manager 9.2.21, kernel 7.0.14-25-pve (previously pinned to 6.17.13-21 because of the igc issue in this thread).

Workaround active during the test:
- kernel cmdline: pcie_aspm=off nvme_core.default_ps_max_latency_us=0
- EEE disabled on the NIC (ethtool --show-eee: disabled, Tx LPI disabled)

Result after 40 h 34 min uptime under normal load (~15 M RX / 18 M TX packets):
- journalctl -k since boot: no tx_timeout, watchdog, reset, link down or AER messages – only the initial "NIC Link is Up 2500 Mbps"
- ethtool -S: tx_timeout_count 0, rx_errors/tx_errors 0, rx_missed_errors 0
- rx_fifo_errors 300 (rx_queue drops 157 + 143, ~0.002 % of RX packets), not increasing in a follow-up check
- no gaps in monitoring > 2 min

Caveats:
- The 7.0.14-25 changelog does not mention igc/i226, so I can't attribute this to a kernel fix.
- I did NOT test without pcie_aspm=off / EEE off – this only shows that 7.0.14-25 + workaround is stable here, not that the workaround is no longer needed.
- I've now pinned 7.0.14-25 and will report back if the issue shows up later.