Detected Hardware Unit Hang - Pve Host verliert quorum und wird unresponsive

nhh

New Member
Sep 25, 2025
12
4
3
Code:
Jul 21 12:45:37 XXXXXX kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
                                   TDH                  <32>
                                   TDT                  <38>
                                   next_to_use          <38>
                                   next_to_clean        <31>
                                 buffer_info[next_to_clean]:
                                   time_stamp           <14660e9db>
                                   next_to_watch        <32>
                                   jiffies              <14660f2c0>
                                   next_to_watch.status <0>
                                 MAC Status             <80083>
                                 PHY Status             <796d>
                                 PHY 1000BASE-T Status  <3c00>
                                 PHY Extended Status    <3000>
                                 PCI Status             <10>
Jul 21 12:45:38 XXXXX corosync[1547]:   [TOTEM ] Token has not been received in 2737 ms
Jul 21 12:45:38 XXXXX corosync[1547]:   [TOTEM ] A processor failed, forming new configuration: token timed out (3650ms), waiting 4380ms for consensus.
Jul 21 12:45:39 XXXXX kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:


Linux 7.0.14-4-pve (2026-07-07T07:27Z)
pve-manager/9.2.4/5e5ae681198514d4


Kennt das jemand? Wir hatten schon öfter Probleme mit dem e100e treiber. Eine Replication scheint das Problem ausgelöst zu haben. Ist das Netzwerkinterface einfach instabil, oder ist das Software? Danke schonmal für Tipps

EDIT: Mehr Info zu der Hardware:

Code:
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (17) I219-LM (rev 11)
        DeviceName: Onboard ETHERNET Controller
        Subsystem: Lenovo Device 1055
        Kernel driver in use: e1000e
        Kernel modules: e1000e
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
        Subsystem: Realtek Semiconductor Co., Ltd. TP-Link TG-3468 v4.0 Gigabit PCI Express Network Adapter
        Kernel driver in use: r8169
        Kernel modules: r8169
 
Last edited:
KI hat vorgeschlagen:

1. Wenn du remote bist: über die Realtek-NIC oder lokal an der Konsole arbeiten. Sonst nohup-Variante nehmen.
2. ethtool -K eno1 tso off gso off gro off → beobachten (dmesg -w | grep e1000e).
3. Prüfen, ob's gesetzt ist: ethtool -k eno1 | grep -E 'tcp-seg|generic'.
4. Wenn ruhig → systemd-Unit enable --now zum Persistieren.
5. pcie_aspm=off nur, falls es weiterhin hängt — und dann eingeplant mit Reboot.

Code:
[Unit]
  Description=Disable TSO/GSO/GRO on eno1 (e1000e I219 TX hang workaround)
  After=network.target


  [Service]
  Type=oneshot
  ExecStart=/sbin/ethtool -K eno1 tso off gso off gro off


  [Install]
  WantedBy=multi-user.target

Hat jemand ne Meinung dazu?
 
Wie ist denn sonst eurer Netzwerk und Storage aufgebaut? Habt ihr eigene Netzwerke für den regulären Traffic,Corosync und die Replikation oder alles über die gleiche Leitung? Wieviele Knoten sind im Cluster und was für SSDs oder HDDs habt ihr im Einsatz?
 
KI hat vorgeschlagen:



Code:
[Unit]
  Description=Disable TSO/GSO/GRO on eno1 (e1000e I219 TX hang workaround)
  After=network.target


  [Service]
  Type=oneshot
  ExecStart=/sbin/ethtool -K eno1 tso off gso off gro off


  [Install]
  WantedBy=multi-user.target

Hat jemand ne Meinung dazu?
Meine Meinung:
Wenn jemand die Ergüsse einer KI in ein Forum stellt, damit sie bewertet wird, aus dem sich eine KI maßgeblich bedient, dann platzt mir fast der Sack!
Glaubst du wirklich irgendwer hier will über solche KI-Ergüsse nachdenken und gar bewerten?
Oder bist du nur hochgradig impertinent?

 
Last edited:
  • Like
Reactions: GMBauer and CoolTux
Meine Meinung:
Wenn jemand die Ergüsse einer KI in ein Forum stellt, damit sie bewertet wird, aus dem sich eine KI maßgeblich bedient, dann platzt mir fast der Sack!
Glaubst du wirklich irgendwer hier will über solche KI-Ergüsse nachdenken und gar bewerten?
Oder bist du nur hochgradig impertinent?

Ich bin ja zugegeben auch jemand, der sich gerne mal aufregt. Aber war das jetzt nicht ein bisschen drüber? :oops:

Nur so als Einschätzung meinerseits: Jemand hat keinen großen Plan von der Thematik, noch will er sich eingehend damit beschäftigen. Also fragt er die allmächtige KI. Ich unterstelle mal, dass das Vorgehen nicht auf Mutwilligkeit basiert, sondern einfach für viele Leute inzwischen die "Alternative" zum selbst denken darstellt. Und neben der KI fragt man dann eben gleich noch zusätzlich die, die sonst die KI indirekt füttern. Schadet ja nicht, wenn die auch noch denken! :cool:

Meiner Meinung nach auch sehr lustig, dass man in der gleichen Zeit in der Forensuche locker haufweise 1A Treffer gehabt hätte. Aber vielleicht ist ja noch ein Lerneffekt diesbezüglich möglich. Man weiß ja nie... :)
 
Der ethtool-Workaround ist der Standard-Fix für die e1000e-Hänger, ziemlich egal ob den jetzt ne KI oder ein Mensch vorschlägt. tso off gso off gro off auf dem I219 hat bei mir die "Detected Hardware Unit Hang" zuverlässig weggeräumt. Die systemd-Unit zum Persistieren passt so, alternativ tuts auch ein post-up /sbin/ethtool -K eno1 tso off gso off gro off in der /etc/network/interfaces, Geschmackssache.

Das ist ein bekannter Treiber/Hardware-Bug der Intel-I219, kein Cluster-Problem an sich. Der Corosync-Token-Timeout ist nur die Folge, weil die NIC beim Hang für ein paar Sekunden komplett steht und dann das Token nicht durchkommt.

Was mich stutzig macht: läuft Corosync bei euch über genau die eno1, die da hängt? Wenn ja, würd ich Corosync mittelfristig auf ein eigenes Netz legen bzw. einen zweiten Ring über die Realtek ziehen. Dann fliegt dir der Node nicht gleich aus dem Quorum, nur weil die Onboard-NIC mal zickt. @Johannes S seine Frage nach eurem Netz-/Storage-Aufbau zielt genau da drauf.
 
  • Like
Reactions: Johannes S