Proxmox VE 9.2 – kompletter Host-Freeze / Hardreset nötig

Serielle Konsole hat der HM80 leider gar keine, ist ein Mini-PC ohne COM-Port und ohne Header auf dem Board. USB-Serial bringt dir da auch nichts, im harten Hänger ist der USB-Stack meist mit tot. Bleibt also netconsole oder pstore, und bei pstore lohnt es sich vorher zu schauen ob überhaupt ein Backend da ist: ls /sys/fs/pstore und dmesg | grep -i pstore nach dem Boot. Bei vielen Consumer-Boards ist kein ERST im Firmware drin, dann landet dort schlicht nichts. Zur Not kann man sich ramoops über die Kernel-Cmdline auf einen reservierten RAM-Bereich legen, das überlebt einen Warmreset meistens. Bin mir aber nicht sicher wie zuverlässig das auf der AMD-Kiste ist, müsste man einfach mal probieren.
 
Bin zwar ein Absoluter Neuling (also bisher gar nichts mit Linux oder Proxmox zu tun), aber tatsächlich habe ich genau das gleiche Problem:


Fehlerbild​

Der Proxmox-Host friert sporadisch komplett ein. Je nachdem läuft das teil mal zwei Tage, oder stürzt auch schon nach 30 Minuten erneut ab.

  • Web-GUI nicht mehr erreichbar
  • SSH nicht mehr erreichbar
  • Netzwerk reagiert nicht mehr
  • Host-Konsole reagiert nicht mehr
  • es hilft nur ein Hardreset
Bisher konnte ich keinen eindeutigen Fehler in einem Log finden.

Proxmox VE 9.2.11

Getestete Kernel:

7.0.14-15-pve
6.17.09-1-pve

Hardware ist ein HP EliteDesk 800 G5, i5-9600T, 16 GB, 512GB

- SSD wurde bereits ersetzt
- es wird absolut nichts zum Zeitpunkt des Systemabsturzes geloogt. höhrt einfach auf.
- Diverse Energiesparmaßnahmen abgeschlatet: GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1 processor.max_cstate=1 pcie_aspm=off nvme_core.default_ps_max_latency_us=0 nvme_core.multipath=N i915.enable_dc=0"
- Dachte unter Anderem es hätte ein Pproblem mit dem Netzwerk und der NAS die nicht dauerhaft an ist. Die wird nun aber gemountet wenn es notwendig ist und danach auch wieder unmountet, bevor die NAS selbst wieder abgeschaltet wird.
- modprobe netconsole netconsole=6666@<host-ip>/<nic>,6666@<ziel-ip>/<ziel-mac> hat auch absolut nichts bezüglich des Absturzes angezeigt
 
Last edited:
Guten Tag, auch hier Mal nach e1000 hang o.ä. sowohl im Log als auch im Forum suchen. Wenn auch verwöhnt, für die Lösung gibt's sogar nen Helperscript. Das ist das Wahrscheinlichste, aber ohne log, kann es natürlich auch eine undichte Wasserleitung sein, die sporadisch auf exakt die gleiche Stelle auf dem Board tropft. Also erstmal im Log suchen "e1000 hang". Das hat mich am Anfang auch Nerven gekostet. Aber nicht aufgeben, man wird immer etwas besser und nach und nach, wenn man gewillt ist etwas zu lesen, Doku zu suchen... versteht man zuerst die Lösungen und kommt immer öfter selbst auf welche .

Beste Grüße

J.W. Schlinkheider
 
JanWerner said:
Guten Tag, auch hier Mal nach e1000 hang o.ä. sowohl im Log als auch im Forum suchen. Wenn auch verwöhnt, für die Lösung gibt's sogar nen Helperscript. Das ist das Wahrscheinlichste, aber ohne log, kann es natürlich auch eine undichte Wasserleitung sein, die sporadisch auf exakt die gleiche Stelle auf dem Board tropft. Also erstmal im Log suchen "e1000 hang". Das hat mich am Anfang auch Nerven gekostet. Aber nicht aufgeben, man wird immer etwas besser und nach und nach, wenn man gewillt ist etwas zu lesen, Doku zu suchen... versteht man zuerst die Lösungen und kommt immer öfter selbst auf welche .

Beste Grüße

J.W. Schlinkheider
Click to expand...
Danke für die Rückmeldung. hatte ich vergessen. Ich hatte schon in /etc/networks/interfaces: stehen:
iface eno1 inet manual
post-up ethtool -K eno1 gso off tso off gro off tx off rx off sg off rxvlan off txvlan off

aber hat eben auch nichts gebracht.

und aus dem log werde ich auch nicht schlau:

Sep 19 12:07:44 Proxmox-PC systemd[1]: run-user-1001.mount: Deactivated successfully.
Sep 19 12:07:44 Proxmox-PC systemd[1]: user-runtime-dir@1001.service: Deactivated successfully.
Sep 19 12:07:44 Proxmox-PC systemd[1]: Stopped user-runtime-dir@1001.service - User Runtime Directory /run/user/1001.
Sep 19 12:07:44 Proxmox-PC systemd[1]: Removed slice user-1001.slice - User Slice of UID 1001.
Sep 19 12:07:44 Proxmox-PC systemd[1]: user-1001.slice: Consumed 2.168s CPU time, 88.6M memory peak.
Sep 19 12:17:01 Proxmox-PC CRON[11520]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Sep 19 12:17:01 Proxmox-PC CRON[11522]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Sep 19 12:17:01 Proxmox-PC CRON[11520]: pam_unix(cron:session): session closed for user root
Sep 19 12:17:53 Proxmox-PC kernel: snd_hda_codec_intelhdmi hdaudioC0D2: HDMI: pin NID 0x5 not registered
Sep 19 12:27:33 Proxmox-PC pvedaemon[1061]: <root@pam> successful auth for user 'root@pam'
Sep 19 12:29:27 Proxmox-PC pveproxy[1076]: worker exit
Sep 19 12:29:27 Proxmox-PC pveproxy[1075]: worker 1076 finished
Sep 19 12:29:27 Proxmox-PC pveproxy[1075]: starting 1 worker(s)
Sep 19 12:29:27 Proxmox-PC pveproxy[1075]: worker 14336 started
Sep 19 12:42:33 Proxmox-PC pvedaemon[1059]: <root@pam> successful auth for user 'root@pam'
Sep 19 12:46:57 Proxmox-PC pveproxy[6627]: worker exit
Sep 19 12:46:57 Proxmox-PC pveproxy[1075]: worker 6627 finished
Sep 19 12:46:57 Proxmox-PC pveproxy[1075]: starting 1 worker(s)
Sep 19 12:46:57 Proxmox-PC pveproxy[1075]: worker 18273 started
Sep 19 12:49:33 Proxmox-PC pveproxy[8578]: worker exit
Sep 19 12:49:33 Proxmox-PC pveproxy[1075]: worker 8578 finished
Sep 19 12:49:33 Proxmox-PC pveproxy[1075]: starting 1 worker(s)
Sep 19 12:49:33 Proxmox-PC pveproxy[1075]: worker 18842 started
Sep 19 12:54:26 Proxmox-PC pvedaemon[1061]: <root@pam> successful auth for user 'root@pam'
Sep 19 13:06:11 Proxmox-PC pvedaemon[1061]: <root@pam> successful auth for user 'root@pam'
Sep 19 13:09:28 Proxmox-PC pveproxy[14336]: worker exit
Sep 19 13:09:28 Proxmox-PC pveproxy[1075]: worker 14336 finished
Sep 19 13:09:28 Proxmox-PC pveproxy[1075]: starting 1 worker(s)
Sep 19 13:09:28 Proxmox-PC pveproxy[1075]: worker 23344 started
lines 972-1000/1000 (END)
 
Last edited:
@Query, dass netconsole nichts gezeigt hat bedeutet, dass nichts angekommen ist. Prüf mal ob der Weg überhaupt steht: auf dem Zielrechner nc -u -l 6666 laufen lassen und auf dem Host echo "test" > /dev/kmsg absetzen. Kommt das nicht an, war die Config von Anfang an tot und du hast nie was mitgeschnitten. Klassiker ist die Ziel-MAC, die muss die MAC des nächsten Hops sein (vom Router), wenn das Ziel nicht im selben Subnetz hängt. Nicht die des Zielrechners.

Und du hast auf dem EliteDesk was, das der HM80 nicht hat: der 9600T ist vPro-fähig, d.h. AMT mit Serial-over-LAN. Im MEBx aktivieren, dann kommt ein zusätzlicher COM-Port raus. Mit dmesg | grep ttyS checken welcher es ist (meist nicht ttyS0), dann als console= in die Kernel-Cmdline und per amtterm mitloggen. Das läuft über die ME, nicht über die CPU, da siehst du noch was wenn der Kernel schon hängt. Viele G5 haben zusätzlich noch einen echten COM-Header auf dem Board, lohnt sich mal reinzuschauen.

Btw, dein Fall ist Intel-Plattform, der vom TO AMD. Wenn dasselbe auf anderer Hardware auftaucht, ist es eher kein einzelner HW-Bug. Ein sauberer Trace von einem von euch beiden braucht ihr. Mach am besten nen eigenen Thread auf, sonst vermischen sich hier die zwei Fehlerbilder.
 
  • Like
Reactions: JanWerner
Bu66as said:
@Query, dass netconsole nichts gezeigt hat bedeutet, dass nichts angekommen ist. Prüf mal ob der Weg überhaupt steht: auf dem Zielrechner nc -u -l 6666 laufen lassen und auf dem Host echo "test" > /dev/kmsg absetzen. Kommt das nicht an, war die Config von Anfang an tot und du hast nie was mitgeschnitten. Klassiker ist die Ziel-MAC, die muss die MAC des nächsten Hops sein (vom Router), wenn das Ziel nicht im selben Subnetz hängt. Nicht die des Zielrechners.

Und du hast auf dem EliteDesk was, das der HM80 nicht hat: der 9600T ist vPro-fähig, d.h. AMT mit Serial-over-LAN. Im MEBx aktivieren, dann kommt ein zusätzlicher COM-Port raus. Mit dmesg | grep ttyS checken welcher es ist (meist nicht ttyS0), dann als console= in die Kernel-Cmdline und per amtterm mitloggen. Das läuft über die ME, nicht über die CPU, da siehst du noch was wenn der Kernel schon hängt. Viele G5 haben zusätzlich noch einen echten COM-Header auf dem Board, lohnt sich mal reinzuschauen.

Btw, dein Fall ist Intel-Plattform, der vom TO AMD. Wenn dasselbe auf anderer Hardware auftaucht, ist es eher kein einzelner HW-Bug. Ein sauberer Trace von einem von euch beiden braucht ihr. Mach am besten nen eigenen Thread auf, sonst vermischen sich hier die zwei Fehlerbilder.
Click to expand...
ja es kommt was an. lass mit ständig was ausgeben:
2026-09-19 17:06:07 [ 1327.597419] HB temp=+43.0°C mhz=82 load=0.19
2026-09-19 17:07:07 [ 1387.608470] HB temp=+41.0°C mhz=82 load=0.07
2026-09-19 17:08:07 [ 1447.620458] HB temp=+41.0°C mhz=82 load=0.17
2026-09-19 17:09:03 [ 1503.966125] test
2026-09-19 17:09:07 [ 1507.632154] HB temp=+41.0°C mhz=82 load=0.21
 
Query said:
Danke für die Rückmeldung. hatte ich vergessen. Ich hatte schon in /etc/networks/interfaces: stehen:
iface eno2 inet manual
post-up ethtool -K eno2 tso off gso off
Click to expand...
Mit ethtool -k eno2 | grep -E 'tcp-segmentation|generic-segmentation' kannst du überprüfen, ob die Angabe aktiv ist. Evtl. musst du für die Prüfung ethtool nachinstallieren.
Deine Schnittstelle eno2 wirkt schon ein wenig "anders". in Standardinstallationen ist das i.d.R. eno1.
 
TErxleben said:
Mit ethtool -k eno2 | grep -E 'tcp-segmentation|generic-segmentation' kannst du überprüfen, ob die Angabe aktiv ist. Evtl. musst du für die Prüfung ethtool nachinstallieren.
Deine Schnittstelle eno2 wirkt schon ein wenig "anders". in Standardinstallationen ist das i.d.R. eno1.
Click to expand...
Sorry. copy und paste, aber leider das falsche. steht tatsächlich genau so nun in der datei:
Code: 
iface eno1 inet manual
        post-up ethtool -K eno1 gso off tso off gro off tx off rx off sg off rxvlan off txvlan off
 
Gut, dann steht der Weg zumindest. Damit ist der nächste Freeze der eigentliche Test: wenn der Heartbeat mittendrin abreißt und danach nichts mehr kommt, hast du einen harten Hänger ohne Oops. Ein e1000-Hang würde vorher normal noch Zeilen rausschieben, das sieht man eigentlich immer. Dreh das HB-Intervall ruhig auf 5 oder 10s runter, dann weißt du hinterher wenigstens sekundengenau wann Schluss war.

Und pack noch den NMI-Watchdog dazu, nmi_watchdog=panic auf die Cmdline bzw. kernel.hardlockup_panic=1. Die Softlockup-Erkennung greift nur solange Interrupts noch durchlaufen, bei einem echten Hardlockup mit abgeschalteten IRQs siehst du ohne NMI-Watchdog gar nichts. Der feuert über NMI und schafft es noch, den Trace über netconsole rauszuschieben.

Was sagt bei dir eigentlich ethtool -i eno1? Die Offload-Geschichten abzudrehen bringt nur was, wenn da auch wirklich e1000e als Treiber steht.
 
Query said:
Sorry. copy und paste, aber leider das falsche. steht tatsächlich genau so nun in der datei:
Code: 
iface eno1 inet manual
        post-up ethtool -K eno1 gso off tso off gro off tx off rx off sg off rxvlan off txvlan off
Click to expand...
Ja und was meldet nun
ethtool -k eno1 | grep -E 'tcp-segmentation|generic-segmentation'?
off oder on?
 
Bu66as said:
Gut, dann steht der Weg zumindest. Damit ist der nächste Freeze der eigentliche Test: wenn der Heartbeat mittendrin abreißt und danach nichts mehr kommt, hast du einen harten Hänger ohne Oops. Ein e1000-Hang würde vorher normal noch Zeilen rausschieben, das sieht man eigentlich immer. Dreh das HB-Intervall ruhig auf 5 oder 10s runter, dann weißt du hinterher wenigstens sekundengenau wann Schluss war.

Und pack noch den NMI-Watchdog dazu, nmi_watchdog=panic auf die Cmdline bzw. kernel.hardlockup_panic=1. Die Softlockup-Erkennung greift nur solange Interrupts noch durchlaufen, bei einem echten Hardlockup mit abgeschalteten IRQs siehst du ohne NMI-Watchdog gar nichts. Der feuert über NMI und schafft es noch, den Trace über netconsole rauszuschieben.

Was sagt bei dir eigentlich ethtool -i eno1? Die Offload-Geschichten abzudrehen bringt nur was, wenn da auch wirklich e1000e als Treiber steht.
Click to expand...
ja ist der e1000e:
Code: 
ethtool -i eno1
driver: e1000e
version: 7.0.14-15-pve
firmware-version: 0.5-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
 
Query said:
ja es kommt was an. lass mit ständig was ausgeben:
2026-09-19 17:06:07 [ 1327.597419] HB temp=+43.0°C mhz=82 load=0.19
2026-09-19 17:07:07 [ 1387.608470] HB temp=+41.0°C mhz=82 load=0.07
2026-09-19 17:08:07 [ 1447.620458] HB temp=+41.0°C mhz=82 load=0.17
2026-09-19 17:09:03 [ 1503.966125] test
2026-09-19 17:09:07 [ 1507.632154] HB temp=+41.0°C mhz=82 load=0.21
Click to expand...
das AMT mit Serial-over-LAN und das mitzuloggen bekomm ich einfach nicht auf die Kette.
Aber über /dev/kmsg funktioniert es. Das schreibe ich nun alle 10 Sekunden in eine Datei auf einem anderen Rechner um es zu protokollieren
 
TErxleben said:
Ja und was meldet nun
ethtool -k eno1 | grep -E 'tcp-segmentation|generic-segmentation'?
off oder on?
Click to expand...
ethtool -k eno1 | grep -E 'tcp-segmentation|generic-segmentation'
tcp-segmentation-offload: off
tx-tcp-segmentation: off
generic-segmentation-offload: off
 
Dann kannst du die e1000e-Spur eigentlich abhaken: Offloads sind aus, und ein echter Unit Hang würde vorher Detected Hardware Unit Hang ins Log schreiben. Bei dir hört das Log einfach mittendrin auf, das ist was anderes.

Aber prüf vorher noch: was sagt cat /proc/cmdline? Wenn PVE auf ZFS läuft, bootet die Kiste über systemd-boot und /etc/default/grub wird komplett ignoriert, die Parameter müssen dann in /etc/kernel/cmdline und danach proxmox-boot-tool refresh. Hab ich schon mehrfach gesehen, dass jemand tagelang C-States und ASPM "aus" hatte und die Zeile nie angekommen ist. Tauchen deine pcie_aspm=off und Co. da nicht auf, hast du bisher schlicht ohne die Workarounds getestet.

AMT kannst du dir sparen solange der kmsg-Stream steht. Ist nmi_watchdog=panic inzwischen drin?
 
Bu66as said:
Dann kannst du die e1000e-Spur eigentlich abhaken: Offloads sind aus, und ein echter Unit Hang würde vorher Detected Hardware Unit Hang ins Log schreiben. Bei dir hört das Log einfach mittendrin auf, das ist was anderes.

Aber prüf vorher noch: was sagt cat /proc/cmdline? Wenn PVE auf ZFS läuft, bootet die Kiste über systemd-boot und /etc/default/grub wird komplett ignoriert, die Parameter müssen dann in /etc/kernel/cmdline und danach proxmox-boot-tool refresh. Hab ich schon mehrfach gesehen, dass jemand tagelang C-States und ASPM "aus" hatte und die Zeile nie angekommen ist. Tauchen deine pcie_aspm=off und Co. da nicht auf, hast du bisher schlicht ohne die Workarounds getestet.

AMT kannst du dir sparen solange der kmsg-Stream steht. Ist nmi_watchdog=panic inzwischen drin?
Click to expand...

Die Boot-Parameter greifen alle bereits sauber und sind aktiv geladen. nmi_watchdog=panic ist drin.

Hier ist die Ausgabe von cat /proc/cmdline:

BOOT_IMAGE=/boot/vmlinuz-7.0.14-15-pve root=UUID=f978e68f-30cf-4278-af75-16b78c951dab ro quiet intel_idle.max_cstate=1 processor.max_cstate=1 pcie_aspm=off nvme_core.default_ps_max_latency_us=0 nvme_core.multipath=N i915.enable_dc=0 console=tty0 console=ttyS4,115200n8 nmi_watchdog=panic
 
You must log in or register to reply here.
Top Bottom
Back