I’m troubleshooting steadily increasing receive CRC errors on my onboard Intel Ethernet controller. Has anyone encountered this combination or found a driver/firmware workaround?

Hardware/software:

• ASRock Z690 Taichi, BIOS 22.01; Intel i9-13900K

• Unraid 7.3.2, kernel 6.18.38-Unraid

• Intel I219-V (17), PCI ID 8086:1a1d, revision 11

• Driver e1000e, firmware 2.3-4

• Link negotiates at 1000 Mb/s, full duplex

Symptoms and testing:

• Receive CRC errors increase during traffic. rx_errors is approximately twice rx_crc_errors; transmit errors and collisions remain zero.

• Replaced Ethernet cable, changed router port, and moved the connection from direct OpenWrt to a Netgear switch. Errors persisted.

• Through Netgear, a 40-second sample added 180 CRC errors over approximately 387 MB received.

• Tested EEE enabled → disabled → restored, with 30-second samples. Disabling EEE did not help.

• Errors also occurred during a local LAN transfer, independent of the ISP/download provider.

• No NVM checksum initialization error has been observed.

Working workaround:

The second onboard Killer E3000 controller, using r8169, received approximately 796 MB with zero receive/CRC/transmit errors. It is now primary in an active-backup bond; Intel is the backup. Controlled link failover worked.

I found older I219-V CRC reports and a historical driver power-management fix, but those concern an earlier controller generation.

Are there known issues with this controller on the current Unraid kernel? What targeted diagnostics or reversible tests would help distinguish an e1000e/firmware/power-management issue from failing hardware?

Your cable, switch, local-transfer, and EEE tests help narrow this down. The clean result from the Killer interface makes the Intel interface the main suspect, but does not yet prove faulty hardware.

Did this start after an Unraid upgrade, and was the Intel interface previously error-free on another version?

Please attach fresh diagnostics from Tools → Diagnostics, collected immediately after a transfer that increases the CRC counter. Also provide these outputs for the physical Intel interface, replacing ethX with its current name:

ethtool -i ethX

ethtool ethX

ethtool --show-eee ethX

ethtool -S ethX

Capture ethtool -S ethX before and after the transfer, and note the duration and amount received. Since Intel is now the backup, confirm that the test traffic actually passes through it.

The roughly 2:1 error ratio does not by itself indicate two separate faults. The driver calculates rx_errors from several counters, including CRC errors. The full counter output will help identify which counters increase.

During planned downtime, the most useful next comparison would be the same LAN transfer under a live Linux USB with a different kernel. Leave the array disks unmounted. Use the same Intel port, cable, switch port, link speed, and MTU.

If that comparison is clean, it would point toward software or configuration. Errors across operating systems would strengthen the hardware or firmware explanation. Keep the working Killer interface for normal use while investigating.