e1000e eno1: Detected Hardware Unit Hang:

I've proxmox 9 (Linux pve 6.14.11-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-2 (2025-09-12T09:46Z) x86_64 GNU/Linux)
this morning the driver fails. but i've a clear installation without any changes in /etc/network/interface


Sep 24 06:13:14 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
TDH <f6>
TDT <d>
next_to_use <d>
next_to_clean <f5>
buffer_info[next_to_clean]:
time_stamp <14622b919>
next_to_watch <f6>
jiffies <14622c4c0>
next_to_watch.status <0>
MAC Status <40080083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
 
Last edited:
Just experienced my first hang, but posted in a separate thread.
Been running for more than a year on 8.x.x, wo. any issues.
Upgraded to 9.x.x a few weeks ago , and have my first hang now.


*******************************

Hardware :
HP Prodesk 600 G5 - Mini

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)

root@prox-01:~# lspci -nnk | grep -A2 Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10)
DeviceName: Onboard Lan
Subsystem: Hewlett-Packard Company Device [103c:8598]
root@prox-01:~#

*******************************

Virtual Environment 9.0.10, Fully udated this week.

root@prox-01:~# uname -a
Linux prox-01 6.14.11-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.11-2 (2025-09-12T09:46Z) x86_64 GNU/Linux
root@prox-01:~#

*******************************
2025-09-27T06:34:36.839088+02:00 prox-01 kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
2025-09-27T06:34:36.839114+02:00 prox-01 kernel: TDH <98>
2025-09-27T06:34:36.839117+02:00 prox-01 kernel: TDT <81>
2025-09-27T06:34:36.839119+02:00 prox-01 kernel: next_to_use <81>
2025-09-27T06:34:36.839120+02:00 prox-01 kernel: next_to_clean <97>
2025-09-27T06:34:36.839122+02:00 prox-01 kernel: buffer_info[next_to_clean]:
2025-09-27T06:34:36.839124+02:00 prox-01 kernel: time_stamp <130eaba7a>
2025-09-27T06:34:36.839125+02:00 prox-01 kernel: next_to_watch <98>
2025-09-27T06:34:36.839127+02:00 prox-01 kernel: jiffies <130eac301>
2025-09-27T06:34:36.839129+02:00 prox-01 kernel: next_to_watch.status <0>
2025-09-27T06:34:36.839130+02:00 prox-01 kernel: MAC Status <80083>
2025-09-27T06:34:36.839132+02:00 prox-01 kernel: PHY Status <796d>
2025-09-27T06:34:36.839133+02:00 prox-01 kernel: PHY 1000BASE-T Status <3800>
2025-09-27T06:34:36.839135+02:00 prox-01 kernel: PHY Extended Status <3000>
2025-09-27T06:34:36.839137+02:00 prox-01 kernel: PCI Status <10>

*******************************

Full info here
B

Thread 'I had my first "hang" today (ve 9.0.10) - eno1: Detected Hardware Unit Hang:'

*******************************
My Proxmox has been running wo. a hitch, since i installed 8.xx , about a year ago.

I had my first "Hang" today @06:36
Discovered by my inability to logon to the Proxmox web GUI.
The node was "unpingable" , and all VM's unreachable.


*******************************

Hardware :
HP Prodesk 600 G5 - Mini

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)

root@prox-01:~# lspci -nnk | grep -A2 Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10)...
 
I also encountered the freezing issue, but when I disabled VLAN Aware and removed the Linux VLAN from the Proxmox network settings, the problem was resolved.

Code: 
root@Fehu:~# uname -r
6.8.12-15-pve
root@Fehu:~# lspci | grep 00:19.0
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
root@Fehu:~#
 
xPadla said:
I also encountered the freezing issue, but when I disabled VLAN Aware and removed the Linux VLAN from the Proxmox network settings, the problem was resolved.

Code: 
root@Fehu:~# uname -r
6.8.12-15-pve
root@Fehu:~# lspci | grep 00:19.0
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
root@Fehu:~#
Click to expand...
My Proxmox would be unusable wo. Vlan support
 
Yet another hang

..
..

B

Post in thread 'I had my first "hang" today (ve 9.0.10) - eno1: Detected Hardware Unit Hang:'

I'm in the summerhouse , but lost my Proxmox server again, this morning.
I can't be 100% sure, but my "gutfeeling" says "Network hang" ....

I'll be trying these in /etc/network/interfaces (on their respective interfaces)

Code: 
post-up ethtool -K eno1 tso off
post-up ethtool -K vmbr0 tso off

Source

Will be trying
D

Post in thread 'e1000e eno1: Detected Hardware Unit Hang:'

Just a tip, you only need to add tso off.
There's no need to turn off all others.
I've been using this on /etc/network/interfaces for over 2 years with no issues:

Code: 
post-up ethtool -K eno1 tso off
Code: 
post-up ethtool -K vmbr0 tso off
  • Like
 
i get the hangs too

Code: 
root@pve:~# uname -r
6.8.12-14-pve

root@pve:~# lspci | grep Eth
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)

e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:

working around with the bounce physical on hang method

no replies in a while and a new kernel available

Setting up proxmox-kernel-6.8.12-16-pve-signed (6.8.12-16) ...

will report back if it hangs again
 
Last edited:
I run into the same issue today. It's really odd. First post is more than 6 years old and we have still the issue

Code: 
admin@pve-1:~$ uname -r
6.17.2-1-pve
admin@pve-1:~$ lspci | grep Eth
80:1f.6 Ethernet controller: Intel Corporation Device 550c (rev 10)
admin@pve-1:~$

@emdubs what do you mean w/ "the bounce physical on hang method"?
 
Had this on one of my hosts today:

Nov 29 15:24:37 pve2 kernel: e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang:

The host has been fine for about 12 months. I've only got a single network card (bridged) and 3 VLAN sub interfaces. I've tried the post-up commands above but the post-up command is not found.

I'm running kernel version 6.8.12-17-pve. Any suggestions? Just seems to be an issue when the network card is under load.
 
Found this issue through google. Installed Proxmox v 8.??? in 2023 on generic Intel NUC with a e1000e NIC. Have suffered with a loss of network every 5 - 6 weeks and simply lived with the reboot. Failed once to often while I was away so upgraded bios and Proxmox versions to 8.4.1 including latest kernel version. To much dismay loss of network bug occurred daily - Have implemented the offloading work around and has been stable for a couple of days. The offloading workaround does not appear to have significant impact on my system performance however will monitor (at least tested through iperf) . Is it possible that this issue has been around for last few years and has been exacerbated by the kernel ?? regression. Is it clear whether it is a driver or kernel issue ??. Given how common these NICs are I am surprised the issue has been fixed.
 
I hit this issue recently as well, after upgrading an old Proxmox box that had been running fine for a few years.

I believe it was previously Proxmox 7.0 - then it got upgraded to the latest Proxmox 9.0

I started seeing this issue shortly after that.

I know it's meant to be a very old bug with the Intel e1000/e1000e chipsets - however, I'm curious why this issue didn't arise before - but seems to have only started manifesting recently?

Does anybody have any theories as to why?

In my case, simply disabling tso seemed to work:

Code: 
ethtool -K eno1 tso off
ethtool -K vmbr0 tso off

I'm also curious if disabling it on both eno1 and vmbr0 is required - or if just disabling it on the underlying hardware interface (eno1) is sufficient?
 
Thanks Everyone,

I was about to pull my Optiplex 7050 apart and reseat all the Ram Chips ect. I believe this occurred around the change from Promox 8 to 9. Has had me stumped for a while, so I have tried the above and will post how it goes.
 
Some people still seem to hope for a fix for their i218 and i219.
Sadly this is what big blue documents:
No fix for:
• Intel® Z170, Q170, H170, Q150, B150, H110, HM175, QM175, HM170 and QM170, CM236, CM238
• Intel® Z270, Q270, H270, Q250, B250, X299, C422
• Intel® Z370, H310C, and B365
• Intel® B460, H410
• Skylake U/Y, Kaby Lake U/Y, Kaby Lake U Refresh, Amber Lake Y
Click to expand...

Seems like for other platforms it was somehow fixed. However, on the listed ones, disabling TSO is the only known workaround (there is no fix on the mentioned chipsets).
Consequently, if you have one of those, stop waiting and implement the workaround.

Edit:
And just to make this clear. This is a known and documented Erratum of the i218/i219.

Edit 2:
The really interesting part is that in 2017, there already was a workaround attempt:
https://git.kernel.org/pub/scm/linu...3&id=b10effb92e272051dd1ec0d7be56bf9ca85ab927
But for some reason it seemingly/obviously isn't always applied.
 
Last edited:
  • Like
Reactions: chrisn-au and glcarlos
You must log in or register to reply here.
Top Bottom