e1000 driver hang

Also having this issue on 6.8.12-11-pve. Applied pve script temporarily but would rather keep offloading enabled. Thanks for all the help
 
For me it looks like the only workaround at the moment is to disable the problematic NIC and add a different NIC.
Otherwise you can only choose between having driver hangs or disabling the offloading.
 
You can downgrade the kernel to 6.8.12-8-pve. For me this is the best option actually.

Code: 
proxmox-boot-tool kernel pin 6.8.12-8-pve --next-boot
 
Last edited:
KLez said:
You can downgrade the kernel to 6.8.12-8-pve. For me this is the best option actually.

Code: 
proxmox-boot-tool kernel pin 6.8.12-8-pve --next-boot
Click to expand...
I tried the downgrade to 6.8.12-8 and it helped for some weeks to reduce the hangs to only a view on some days and no hangs on most days. But suddenly on two days the hangs occurred again in thousands.
At that point I updated to the newest kernel and disabled the offloading. After that there where no more driver hang messages in the log file anymore.
In retrospect replacing the NIC would have been easier but not so exciting :)
 
Hello
Faced the same problem saturday :

Code: 
2025-08-02T14:55:43.876603+02:00 orvault-pxmx1 kernel: [179039.679064] e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
2025-08-02T14:55:43.876615+02:00 orvault-pxmx1 kernel: [179039.679064]   TDH                  <f4>
2025-08-02T14:55:43.876616+02:00 orvault-pxmx1 kernel: [179039.679064]   TDT                  <79>
2025-08-02T14:55:43.876616+02:00 orvault-pxmx1 kernel: [179039.679064]   next_to_use          <79>
2025-08-02T14:55:43.876617+02:00 orvault-pxmx1 kernel: [179039.679064]   next_to_clean        <f3>
2025-08-02T14:55:43.876617+02:00 orvault-pxmx1 kernel: [179039.679064] buffer_info[next_to_clean]:
2025-08-02T14:55:43.876617+02:00 orvault-pxmx1 kernel: [179039.679064]   time_stamp           <10aa752f6>
2025-08-02T14:55:43.876618+02:00 orvault-pxmx1 kernel: [179039.679064]   next_to_watch        <f4>
2025-08-02T14:55:43.876618+02:00 orvault-pxmx1 kernel: [179039.679064]   jiffies              <10aa75a00>
2025-08-02T14:55:43.876619+02:00 orvault-pxmx1 kernel: [179039.679064]   next_to_watch.status <0>
2025-08-02T14:55:43.876620+02:00 orvault-pxmx1 kernel: [179039.679064] MAC Status             <80083>
2025-08-02T14:55:43.876620+02:00 orvault-pxmx1 kernel: [179039.679064] PHY Status             <796d>
2025-08-02T14:55:43.876621+02:00 orvault-pxmx1 kernel: [179039.679064] PHY 1000BASE-T Status  <3800>
2025-08-02T14:55:43.876622+02:00 orvault-pxmx1 kernel: [179039.679064] PHY Extended Status    <3000>
2025-08-02T14:55:43.876623+02:00 orvault-pxmx1 kernel: [179039.679064] PCI Status             <10>

rolled back to 6.8.12-8 this morning, wait & see...

Regards
 
New install of proxmox 9 on a cluster of 3 lenovo p330 tiny PCs. Before I had Proxmox 7 and 8, rarely updated though, but running strong 24/7 for 2 years with no problem. With the new proxmox 9 within 4 hours had a network card hang on me.
The reason I don't want to disable any offloading is that for my use-case at least performance is much more important than security, being an isolated home-lab.

Issued these commands to downgrade the kernel on proxmox 9:
Bash: 
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve8.list

apt update
apt install proxmox-kernel-6.8.12-8-pve
proxmox-boot-tool kernel pin 6.8.12-8-pve

I recommend deleting the file /etc/apt/sources.list.d/pve8.list after this.
 
Last edited:
I also have the issue with PVE 9.0.3 and 6.14.8-2-pve kernel.

this didnt help :-(
ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

only manual ifup helps :-(
 
Yesterday, I updated my Intel NUC NUC10i7FNB with the latest firmware/BIOS and installed the current Proxmox 9.04 with kernel 6.14.8-2.
The error remains, so the workaround still needs to be used.

ethtool -K eno1 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off
 
Had this happen in two different hosts. So the current solution is either disabling offloading or downgrading the kernel? It's weird that with me it only happens when I'm running Windows VMs.
 
I have 2 identical machines both running Proxmox (more than a year), I accidentally update one of the machine to latest version and it starting having this issue. I've read a countless thread of this issue but I'm still confused is this a problem on Intel side (driver bug) or is it from Proxmox side? If it's from Intel side, why is the older version of Proxmox doesn't have this issue?

Can this be fixed from Proxmox side and if there's any plan/ETA for the fix? (not workaround like hardware offloading solution).

Thank you
 
The e1000 problem and workaround (disabling offloading) seems to go back a long time. Here is a entry from 2012:
https://bugzilla.kernel.org/show_bug.cgi?id=47331 (first mention of disabling offloading 2019)

Here a full list of topics at the kernel bugzilla:
https://bugzilla.kernel.org/buglist.cgi?quicksearch="Detected Hardware Unit Hang"

I think the driver does not always run into this problem. I have the impression it depends on what kind of services (eg pve+pbs on the same machine) or what kind of vms (eg Windows-VM) and with which guest-drivers you use or whats happening inside the guests (eg client backup software over lan).
Diagnosing the exact source of the problem is difficult because sometimes the system runs for several weeks without serious device hangs before the NIC/driver freezes.
 
TomFIT said:
The e1000 problem and workaround (disabling offloading) seems to go back a long time. Here is a entry from 2012:
https://bugzilla.kernel.org/show_bug.cgi?id=47331 (first mention of disabling offloading 2019)

Here a full list of topics at the kernel bugzilla:
https://bugzilla.kernel.org/buglist.cgi?quicksearch="Detected Hardware Unit Hang"

I think the driver does not always run into this problem. I have the impression it depends on what kind of services (eg pve+pbs on the same machine) or what kind of vms (eg Windows-VM) and with which guest-drivers you use or whats happening inside the guests (eg client backup software over lan).
Diagnosing the exact source of the problem is difficult because sometimes the system runs for several weeks without serious device hangs before the NIC/driver freezes.
Click to expand...
Do you know if turning off onloading will have significant impact on CPU? I have 9th gen Intel CPU and I have 13 cameras recording 24/7 (which is already CPU heavy) into my Frigate LXC.

I've considered migrating from Proxmox as I kept getting this issue when I travel, luckily I can shut and no shut from my Cisco switch to bring it back but it stops recording when it happened.
 
baritone_sax said:
Do you know if turning off onloading will have significant impact on CPU? I have 9th gen Intel CPU and I have 13 cameras recording 24/7 (which is already CPU heavy) into my Frigate LXC.

I've considered migrating from Proxmox as I kept getting this issue when I travel, luckily I can shut and no shut from my Cisco switch to bring it back but it stops recording when it happened.
Click to expand...
I can't tell the impact on your system. On the two of my systems which were affected, it had no practical disadvantage in performance.
You can try the workaround by using the ethtool-command (it's not permanent) and check the performance impact.
If it has no impact, you can add the ethtool-command to your /etc/network/interfaces-file for a permanent setting.
 
Seems to be really just a Linux e1000 driver issue. I have a HP mini PC which supports Intel AMT. I enabled this service now in the Bios to see if it is also effected by the hang. When I got the last NIC hang in Proxmox, AMT was still available and responsive. I could i.e. send commands like reboot.
 
Anyone know if these are something that can be fixed on the Proxmox side? (assuming the issue is coming from Intel side). It's really frustrating I just got hit 3 times in the last 24 hours.
 
You must log in or register to reply here.
Top Bottom