Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[a200]

@crunchip scheint ein bekanntes Problem zu sein:

2025-08-28T14:59:38.912818+02:00 pve kernel: [264641.580371] e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
2025-08-28T14:59:38.912833+02:00 pve kernel: [264641.580371]   TDH                  <7f>
2025-08-28T14:59:38.912835+02:00 pve kernel: [264641.580371]   TDT                  <b0>
2025-08-28T14:59:38.912836+02:00 pve kernel: [264641.580371]   next_to_use          <b0>
2025-08-28T14:59:38.912837+02:00 pve kernel: [264641.580371]   next_to_clean        <7e>
2025-08-28T14:59:38.912839+02:00 pve kernel: [264641.580371] buffer_info[next_to_clean]:
2025-08-28T14:59:38.912840+02:00 pve kernel: [264641.580371]   time_stamp           <10fc1780f>
2025-08-28T14:59:38.912842+02:00 pve kernel: [264641.580371]   next_to_watch        <7f>
2025-08-28T14:59:38.912843+02:00 pve kernel: [264641.580371]   jiffies              <10fc19c80>
2025-08-28T14:59:38.912845+02:00 pve kernel: [264641.580371]   next_to_watch.status <0>
2025-08-28T14:59:38.912858+02:00 pve kernel: [264641.580371] MAC Status             <40080083>
2025-08-28T14:59:38.912860+02:00 pve kernel: [264641.580371] PHY Status             <796d>
2025-08-28T14:59:38.912861+02:00 pve kernel: [264641.580371] PHY 1000BASE-T Status  <3800>
2025-08-28T14:59:38.912862+02:00 pve kernel: [264641.580371] PHY Extended Status    <3000>
2025-08-28T14:59:38.912863+02:00 pve kernel: [264641.580371] PCI Status             <10>

root@pve:~/Marek/Proxmox-logfile# grep "Detected Hardware Unit Hang" a |wc -l
3721

Muss hier weiter gucken: https://forum.proxmox.com/threads/e1000-driver-hang.58284/

Danke.

[crunchip]

@a200 hast du in deiner VM Netzwerk E1000 eingestellt, anstatt VirtIO (paravirtualized)?

[a200]

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

[crunchip]

@a200 virtio sollte keine Probleme bereiten und die Performance ist auch besser

[Kalle Blomquist]

@a200
Wenn bei dir wieder alles läuft und du ein bisschen Zeit hast, schau dir doch mal den Proxmox-Metrikserver an. Damit kann man Probleme schon ganz gut aufspüren.
Siehe:

[David G.]

@a200 sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

@crunchip nein. Aber es scheint weniger mit der VM, als mehr mit Proxmox zu tun haben. e1000 ist das physikalische Device bei dem NUC und das scheint ein Problem bei den neuen Kernels zu machen. Ich habe jetzt die empfohlene offloading Einstellung genommen. Mal sehen wie lange es hält.

Vielen Dank für deine Unterstützung.

ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off

Das kann es gut gewesen sein.
Ich hatte genau das selbe Problem.
Bei mir ist es nach oder bei großen Backups aufgetreten die der PBS über das Internet versendet hat.

Bei mir reicht ein

ethtool -K enp0s31f6 tso off gso off gro off

damit alles sauber läuft.
Hab es allerdings nach den letzten 2-3 reboots nicht mehr gemacht, ka ob sich das Problem mittlerweile gelöst hat....

[isi07]

Ist die Proxmox Installation aktuell? Ich erinner mich, dass ich das beschriebene Verhalten auch mal hatte mit einem NUC und einem e1000 Netzwerkadapter. Hin und wieder war der komplette Host nicht mehr erreichbar und konnte nur über den Knopf aus und wieder eingeschaltet werden. Ist aber bestimmt schon zwei Jahre her.
Bei mir lag es damals an Problemen mit dem Treiber im Kernel. Da musste ich dann für eine weile per dpks (oder so ähnlich) eine neuere Treiberversion hinzufügen. Seit einer Weile läuft bei mir aber alles wieder stabil mit dem aktuellen Kernel ohne Erweiterung.
Vielleicht mal im Proxmox forum suchen.
Viel Erfolg

[David G.]

@isi07

Ich hatte es auf jedem Fall bis vor ca 6 Monaten, System immer aktuell.

Ob es wirklich weg ist, oder nur nicht mehr auftritt weil die großen Backups durch sind weiß ich nicht.
Das Problem trat auch erst seit den großen Backups auf.

[MartinP]

Allgemein an das Forum - welche(n) physischen Netzwerk-Adapter man hat, kann man in der pve Shell folgendermaßen herausfinden:

root@pve:~# lshw -short |grep network
/0/100/1c.3/0          enp3s0     network     RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

[Meister Mopper]

@david-g sagte in IoBroker in VM legt kompletten Proxmox-Server lahm.:

Hab es allerdings nach den letzten 2-3 reboots nicht mehr gemacht, ka ob sich das Problem mittlerweile gelöst hat....

Ich hatte das Problem auch (Kernelversion weiß ich nicht mehr).

Seit Proxmox 9 (auch der neueste Kernel) ist das Problem (noch) nicht wieder aufgetreten.
Toi, toi, toi ...

[a200]

@meister-mopper Moin. Habe am Samstag Upgrade auf Proxmox 9 (6.14.11-1-pve) gemacht. Heute morgen war der Server nicht erreichbar. Also wenigstens für mich ist es keine Lösung. Trotzdem Danke.

[David G.]

@a200

Dann Pack dir den Befehl einfach in den Autostart oder lass ihn ohne Trigger von einem JS oder Blockly (Zb über Linux Control) an Proxmox senden.

[a200]

@david-g Habe auf dem NUC ein Script gebaut:

#!/bin/bash

ROUTER_IP=192.168.10.1
LOGFILE="/var/log/network_check/network_check.log"

if ( ping -c3 $ROUTER_IP >/dev/null 2>&1 )
then
   echo "$(date '+%Y-%m-%d %H:%M:%S') - ping $ROUTER_IP - OK" >> $LOGFILE
else
   echo "$(date '+%Y-%m-%d %H:%M:%S') - ping $ROUTER_IP - ERROR" >> $LOGFILE
   service networking restart  >> $LOGFILE 2>&1
   echo "$(date '+%Y-%m-%d %H:%M:%S') - service networking restart - done" >> $LOGFILE
fi

Auf einem zweiten Proxmox habe ich Gatus: https://gatus.io installiert, dann bekomme ich wenigstens eine Telegram Nachricht geschickt.