e1000: Detected Tx Unit Hang - VMware Workstation 17.6.3 Pro - HAOS 15.2/HA Core 2025.6.2

[chipdarippa]

Describe the issue you are experiencing

Been running HA via VMware Workstation Pro for years now without issue. Maybe 1.5 months ago or so started having issues.

When the web interface hangs and no longer loads, on the VMware workstation window I see the e1000: Detected Tx Unit Hang message just printing over and over again. I have to manually stop the VM and restart it. It locks up within a few days.

What operating system image do you use?

ova (for Virtual Machines)

What version of Home Assistant Operating System is installed?

15.2

Did the problem occur after upgrading the Operating System?

No

Hardware details

Windows 11 Pro
i7-8700
32GB RAM

VMWare Workstation Pro 17.6.3 build-24583834
Only HA VM running

Allocated to HA VM:
2.5GB RAM
2 Processors
32GB hard disk

Steps to reproduce the issue

1. Launch VM
2. Wait for VM to hang - HA app/web GUI connection will not work
3. Check via host's VMware Workstation application HA VM & see repeating "e1000: Detected Tx Unit Hang" messages in console
   ...

Anything in the Supervisor logs that might be useful for us?

Not that I can tell

Anything in the Host logs that might be useful for us?

Not that I can tell

System information

No response

Additional information

No response

[agners]

What adapter type do you use? Maybe try using VMXNET 3 (paravirtualized network device, HAOS should support it) or E1000E.

[chipdarippa]

I use the default, which is the e1000. According to what I could find, it does support the e1000e as well, but when I attempted to manually update the *.vmx config file by changing the ethernet0.virtualDev = "e1000" to "e1000e," the VM would no longer boot. Not sure why.

I did have someone recommend the VMXNET 3 as well, and I attempted to change that same line to use it and it again wouldn't boot.

I then found @ https://www.home-assistant.io/installation/alternative/ that "Use the E1000 or E1000E virtual network adapter. There are confirmed mDNS/Multicast discovery issues when using VMware’s VMXnet3 virtual network adapter." Just FYI.

[chipdarippa]

[agners]

Hm, there are some results on Google where this seems to be a problem. We use vanilla upstream Linux, so that really seems to be some interaction problem between Linux and VMware 🤷

Maybe disabling hardware tso helps? Enter this on the OS shell (use login on the ha prompt to get os shell access)

nmcli con modify "Supervisor eth0" ethtool.feature-tso on
nmcli con up "Supervisor eth0"

(replace connection name with the current active one shown in nmcli con show)

[chipdarippa]

Finally happened again. Made the recommended changes. Thank you for the step-by-step. Is there any way for me to confirm that the changes took effect?

[agners]

ethtool is not available in the root shell. But you can use the "Advanced SSH & Web Terminal" add-on which runs on host network and install ethtool using apk add ethtool, then check using ethtool -k enp0s18 | grep tcp-segmentation-offload. It should be set to "off" after the change is applied.

[chipdarippa]

Made the changes and it happened again.

[Impact123]

Since this is a VM could you not simply choose another NIC type and potentially reset the network?
Also what did ethtool say when used as instructed above?

[cptshrk108]

I have the exact same issue. The VM doesn't boot when trying to change the adapter.

[Impact123]

Doesn't boot is not enough information to help. What does it show?