e1000e eno1: Detected Hardware Unit Hang:

[docstorm]

I just started looking into this issue and found here...testing the tso workaround.

I have three Dell Precision 3431s that use the Q246 C246 chipset. The first one I updated from PVE 8 to 9 started exhibiting this issue...more often when under network load like doing file transfers, but sometimes when it wasn't significant. The other two have not shown the problem...yet.

All are BIOS 1.32.0 (the latest when first deployed). 1.36.0 is out now, but details on fixes are pretty terse.

 

[celemine1gig]

There is no "Q246" chipset, but only a "C246". And as mentioned, the original bug only should still affect older chipsets/systems (list see in my previous comment). So, if the issue persists and was not fixed with a BIOS update, then contact Dell. They should also be aware of this i219 Erratum.

 

[docstorm]

There is no "Q246" chipset, but only a "C246". And as mentioned, the original bug only should still affect older chipsets/systems (list see in my previous comment). So, if the issue persists and was not fixed with a BIOS update, then contact Dell. They should also be aware of this i219 Erratum.

Oops, yes, that was a typo.

 

[r4nd0m]

I have a few NUCs showing this behaviour, on 2 of them I have blacklisted the e1000e driver and use a different NIC which seems to work fine.

What I have noticed though, this only seems to happen on servers hosting VMs, I got one that only hosts LXCs which seems to be running forever and did migrate a VM across as I needed to perform some upgrades, as soon as the VM migrated across and started, the server crashed a few seconds/minutes later with the notorious log entry in the logs when I looked for a reason. When the server came back the upgrades had already completed and I migrated the VM away from the server back to the original hosting LCXs and VMs with the module being blacklisted, no issues whatsoever since.

 

[warheat1990]

Anyone know if the card below is affected by this bug? I have one laying around but not sure about the model, it says Intel PRO

 

[chrisn-au]

I have just asked Claude

The reply was
Yes, almost certainly. Based on the Intel PRO/1000 PT Desktop Adapter identification, the chip under that heatsink is the Intel 82572GI controller, which uses the e1000e driver on Linux.
To confirm, if you have this card installed in a Linux system, you can run:

```
lspci | grep -i ethernet
```

Honestly unless you have high throughput requirements on the card I have seen no obvious impacts of the workaround and would do that

 

[celemine1gig]

See Erratum Nr. 7: https://www.intel.com/content/dam/d...2571eb-82572ei-gbe-controller-spec-update.pdf
Just because it uses the "e1000e" driver does not necessarily mean, that it is affected by this bug.
You have to specifically check the Intel documentation on related topics. The problem might manifest itself slightly differently on those older chipsets. From what I saw, most poeple here saw it with i218/i219.

 

[TheGadMan]

One of the reasons why my setup is still pinned to kernel 6.8.12-8. I've had no issues since rolling back. Honestly have no desire to upgrade until this gets fixed.

If I pin my kernel to 6.8.12-8 can I upgrade all the other packages that need upgrading? I've been holding off

 

[TheGadMan]

Here’s what I did, which has been working for me so far — no network hangs yet.

First, I completely removed the community script (https://community-scripts.github.io/ProxmoxVE/scripts?id=nic-offloading-fix). This simply involved disabling the service and removing the service unit file. The script had actually been working perfectly fine for me, and I never experienced a hang while using it. I mainly removed it because I wanted to apply it manually then update and upgrade my machine. I figured that, worst case, I could downgrade and pin the kernel if needed.

I then applied the community script’s fix manually in /etc/network/interfaces using a post-up command. However, I only disabled TSO and applied it only to the physical Intel NIC — not the vmbr interface.

iface enp0s25 inet manual
        post-up /sbin/ethtool -K $IFACE tso off

I made this change while running kernel 6.8.12-11-pve. After that, I performed a normal update and upgrade through the Proxmox web interface, which upgraded the system to 6.8.12-19-pve.

So far, everything has been running fine. I’ll report back if I experience any network hangs.

admin@prox:~$ lspci | grep Eth
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 05)

 

[rds76]

I could confirm, turning TSO off on phy nic (post-up script) fixed this issues for me as well (I219V), no hangs so far (2w), only slightly higher cpu utilization 1-2% during nic traffic