Moin zusammen,
folgendes Problem: Seit Umzug von HA vom Raspi auf Proxmox habe ich häufig das Problem, dass mir Proxmox “einfriert” - genauer: Es ist über die übliche IP nicht mehr zu erreichen. Damit läuft natürlich auch HA nicht mehr.
Hardware: HP EliteDesk 800 G5 Intel i5-9400T RAM 16GB SSD 480GB über Netgear GS308EP Switch. Alternativ (gleiches Problem) via LAN-Kabel an
TP-Link Deco X50
Proxmox Virtual Environment 8.4.1
Hat vielleicht jemand eine Idee?
Falls Du einen aktuellen Proxmox Kernel (ab 6.8.12-9) nutzt und in der HP Kiste eine Intel NIC verbaut ist, dürfte das wohl (mal wieder) an dem aktuellen e1000 Bug liegen.
Oder auch:
ff.
VG Jim
all right. Dann die Gretchen-Frage: Wie finde ich das raus und wie behebe ich das?
Steht alles in den verlinken Beiträgen 
und daher poste ich das alles hier nicht noch einmal. 
VG Jim
Habe jetzt mal die e1000e Offloads deaktiviert. Wir werden sehen, ob’s das gebracht hat
Hi.
hatte ich auch mal. Lag bei mir daran, dass der Plattenplatz von einem LXC-Container voll war.
Habe auch tagelang nach dem Fehler gesucht und konnte mir hinterher nur vor den Kopf schlagen.
Viele Grüße
Marcel
Abwarten - das Problem ist halt das es viele unterschiedliche Intel NICs in so viel unterschiedlichen Revisions gibt, dass man wirklich nur durch ausprobieren eine Lösung finden kann. Wie Du in dem anderen Postings ja vielleicht gelesen hast habe ich hier u.a. eine I219-LM in meiner Proxmox Kiste und ich nutze auch noch den älteren Kernel 6.8.12-9. Damit habe ich keinerlei Netzwerkabbrüche. Andere User, die ebenfalls den Kernel 6.8.12-9 und eine I219-LM NIC genutzt haben, hatten dann aber Netzwerkabbrüche. D.h. nicht nur die Modellbezeichnung der NIC spielt eine Rolle, sondern halt auch die Revision davon.
Edit:
Das hat dafür gesorgt das Du den Proxmox Host nicht mehr über seine IP erreichen konntest - worum es bei @RudiAndUs ja geht. Das wäre dann schon ziemlich ungewöhnlich.
VG JIm
Kurzes Feedback nach rund einem Monat: Das Problem ist behoben und Proxmox läuft seitdem “like a charm”!
Guten Abend, könntest Du der Community vielleicht erklären, wie man die e1000e Offloads deaktiviert.
Ich bin leider kein Experte und wüsste nicht wie es geht. Wäre wirklich nett von dir.
Moin,
das war ein Fehler in einer 8 Version von Proxmox, aktuell ist die Version 9.0.11 hast Du wirklich noch Probleme?
Ansonsten es gab ein Helferskript, das die Einstellungen im PVE vorgenommen hat,
VG
Bernd
Ich habe Dir mal das Log beigefügt, wenn es Dir reicht. Ich erkenne daraus leider gar nichts, außer, dass es das bekannte Problem ist
Protokoll vom 11.11.2025.txt (48,0 KB)
Das habe ich nun mal gemacht.
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
Hi Bernd,
ne nicht nur in einer 8 Version von Proxmox sondern auch bei älteren Proxmox Versionen war der Bug immer mal wieder und auch bei der 9er Proxmox Version ist er noch vorhanden. 
Das ist ein Kernel Problem und mit dem 6.14.x Kernel ist der Fehler wieder vorhanden. Warum genau weiß glaube ich so niemand wirklich. 
Auch ein Proxmox Entwickler hatte sich vor einer Weile dazu im Proxmox Forum mal geäußert, aber im Prinzip auch nur das sie das Problem auch nicht nachvollziehen und/oder letztendlich beseitigen könnten.
Ich verfolge das Thema zwar nicht regelmäßig weil meine Fujitsu Kiste davon nicht betroffen ist, aber im Proxmox Forum tauchen regelmäßig - auch in den letzten Tagen - immer wieder Postings von Usern auf die von dem Problem - auch mit Proxmox 9 - betroffen sind.
VG Jim
Wäre der Fehler denn mit den Helferscript dann weg oder löst es das Problem dann doch nicht?
Ich nutze die Helper Scripts im Normalfall nicht, aber geh mal davon aus das das Script den passenden Befehl ausführt und es funktioniert. Somit sollte das Problem damit gelöst sein.
VG Jim
Moin,
ja, damit sollte es behoben sein!
Im Einzelnen, wenn es Text und nicht ein Bild wäre, ist da folgendes gemacht worden
Nachgeschaut, ob ein Netzwerk Chip vom Typ e1000(e) verbaut ist
Ja, bei Dir vorhanden
Einen systemd Service erstellt und aktiviert
# ethtool -k eno1
und
# systemctl status disable-nic-offload-eno1.service
Da ich keine e1000(e) habe sieht das bei mir so aus
root@pve-10:~# ethtool -k eno1
Features for eno1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
root@pve-10:~#
Den zweiten Befehl kann ich nicht ausführen, da es den Service bei mir nicht gibt!
VG
Bernd
Habe die beiden Befehle noch nachgeschoben:
root@pve:\~# ethtool -k eno1
Features for eno1:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ipv4: off \[fixed\]
tx-checksum-ip-generic: off
tx-checksum-ipv6: off \[fixed\]
tx-checksum-fcoe-crc: off \[fixed\]
tx-checksum-sctp: off \[fixed\]
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off \[fixed\]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off \[fixed\]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off \[fixed\]
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off \[fixed\]
receive-hashing: on
highdma: on \[fixed\]
rx-vlan-filter: off \[fixed\]
vlan-challenged: off \[fixed\]
tx-gso-robust: off \[fixed\]
tx-fcoe-segmentation: off \[fixed\]
tx-gre-segmentation: off \[fixed\]
tx-gre-csum-segmentation: off \[fixed\]
tx-ipxip4-segmentation: off \[fixed\]
tx-ipxip6-segmentation: off \[fixed\]
tx-udp_tnl-segmentation: off \[fixed\]
tx-udp_tnl-csum-segmentation: off \[fixed\]
tx-gso-partial: off \[fixed\]
tx-tunnel-remcsum-segmentation: off \[fixed\]
tx-sctp-segmentation: off \[fixed\]
tx-esp-segmentation: off \[fixed\]
tx-udp-segmentation: off \[fixed\]
tx-gso-list: off \[fixed\]
tx-nocache-copy: off
loopback: off \[fixed\]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off \[fixed\]
rx-vlan-stag-hw-parse: off \[fixed\]
rx-vlan-stag-filter: off \[fixed\]
l2-fwd-offload: off \[fixed\]
hw-tc-offload: off \[fixed\]
esp-hw-offload: off \[fixed\]
esp-tx-csum-hw-offload: off \[fixed\]
rx-udp_tunnel-port-offload: off \[fixed\]
tls-hw-tx-offload: off \[fixed\]
tls-hw-rx-offload: off \[fixed\]
rx-gro-hw: off \[fixed\]
tls-hw-record: off \[fixed\]
rx-gro-list: off
macsec-hw-offload: off \[fixed\]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off \[fixed\]
hsr-tag-rm-offload: off \[fixed\]
hsr-fwd-offload: off \[fixed\]
hsr-dup-offload: off \[fixed\]
root@pve:\~# systemctl status disable-nic-offload-eno1.service
● disable-nic-offload-eno1.service - Disable NIC offloading for Intel e1000e interface eno1
Loaded: loaded (/etc/systemd/system/disable-nic-offload-eno1.service; enabled; preset: enabled)
Active: active (exited) since Wed 2025-11-12 19:12:21 CET; 1h 10min ago
Invocation: ab55ec3e09c245fca909170908616bee
Main PID: 257856 (code=exited, status=0/SUCCESS)
Mem peak: 1.7M
CPU: 27ms
Nov 12 19:12:21 pve systemd\[1\]: Starting disable-nic-offload-eno1.service - Disable NIC offloading for Intel e1000e interface eno1…
Nov 12 19:12:21 pve systemd\[1\]: Finished disable-nic-offload-eno1.service - Disable NIC offloading for Intel e1000e interface eno1.
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
s.a.: (Neues Update & Features - Hier in der Community 🫶)
Guten Morgen,
ich habe einen Lenovo Tiny m720q, in dem eine nic e1000 verbaut ist. Im April hatte ich dann auch dieses Netzwerkproblem und habe nachdem ich rausgefunden habe, das es an der Netzwerkkarte liegt, mir einen UGREEN USB Hub Ethernet Adapter Gigabit mit 3 USB geholt.
Dieser hat den Chip “AX88179” verbaut.
Eingebaut, die interne deaktiviert und siehe da, es läuft. Bis heute.
Jetzt, seit ca. einer Woche habe ich wieder das Problem. Das System bleibt stehen.
Mit “systemctl restart networking” ist das System sofort wieder da.
Zu Problemen mit dem Chip “AX88179” finde ich aktuell nichts, kann mir jemand sagen ob es tatsächlich damit Probleme gibt oder evtl. habe ich ein anderes Problem, USB Schnittstelle?
Ich habe den Lan Hub, eine SSD für Paperless und eine WD Festplatte direkt am PC angeschlossen. Wobei ich schon die WD Festplatte entfernt hatte, was nichts gebracht hat und gestern habe ich dann auch noch die SSD für Paperless entfernt, jetzt hängt nur noch der Lan Adapter an der Kiste. Noch ist kein Hänger aufgetreten. Aber das heißt nichts.
ChatGPT sagt mit dem aktuellen Kernel gäbe es Probleme aber damals ist die Kiste alle paar Stunden eingefroren, jetzt läuft sie auch mal ein paar Zage am Stück durch und der Hänger kommt plötzlich. Empfohlen wird jetzt der Chip “RTL8153”.
Hier mal die Log Daten,:
[174884.197097] usb 2-3: USB disconnect, device number 3
[174884.197102] usb 2-3.1: USB disconnect, device number 4
[174884.197243] cdc_ncm 2-3.1:2.0 enxusb0: unregister 'cdc_ncm' usb-0000:00:14.0-3.1, CDC NCM (NO ZLP)
[174884.197409] vmbr0: port 1(enxusb0) entered disabled state
[174884.197608] cdc_ncm 2-3.1:2.0 enxusb0 (unregistering): left allmulticast mode
[174884.197611] cdc_ncm 2-3.1:2.0 enxusb0 (unregistering): left promiscuous mode
[174884.197613] vmbr0: port 1(enxusb0) entered disabled state
[174884.424205] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd
[174884.442326] usb 2-3: New USB device found, idVendor=05e3, idProduct=0626
[174884.722235] usb 2-3.1: new SuperSpeed USB device number 6 using xhci_hcd
[174884.739719] usb 2-3.1: New USB device found, idVendor=0b95, idProduct=1790
[174884.787946] cdc_ncm 2-3.1:2.0: MAC-Address: c8:a3:62:2d:d4:fd
[174884.788644] cdc_ncm 2-3.1:2.0 eth0: register 'cdc_ncm'
[174884.796883] cdc_ncm 2-3.1:2.0 enxusb0: renamed from eth0
root@Barf:~# ethtool -i enxusb0
driver: cdc_ncm
version: 6.14.11-4-pve
firmware-version: CDC NCM (NO ZLP)
expansion-rom-version:
bus-info: usb-0000:00:14.0-3.1
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
root@Barf:~# ethtool enxusb0
Settings for enxusb0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Half
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Guten Morgen,
bei der 9.x sind bislang nur Bootprobleme bei Dell Servern im größeren Umfang bekannt geworden.
Bei dir scheint aber das USB Device disconncted, da sieht nach einem anderen Fehler aus…
Der 720q hat doch einen Steckplatz für PCI Karten. Mein Tip: Kauf eine passende PCI Riser Card (sowas z.B.: Riser) und dann eine gebrauchte i350-basierte LAN Karte wie die hier z.B.: Dell i350 Dualport
Die gibt es als 2- und 4-Port. Die 2-Port hat keinen Kühlkörper und passt daher ohne Nacharbeit ins Gehäuse. Musst dann eben das Bracket abdichten, das ist für 4-Port Karten gedacht.
Erstens sind die i350 echte Serverchips mit mehr Durchsatz und zweitens habe ich bei denen noch nie vom e1000 Bug gehört, da die einen anderen Treiber nutzen. Läuft bei mit in einem 720q und einem 920er seit einem Jahr problemlos.
Cu
Frank
Moin
Der AX88179 hat immer mal wieder Probleme gemacht. Je nachdem welchen Kernel man verwendet hat. Siehe z.B.:
Hast Du aktuell irgendwelche Updates bei Proxmox gemacht und z.B. das 9.1.x Update installiert? Falls ja kann es gut möglich sein das mit dem dabei verwendeten Kernel dann das Problem wieder auftaucht. So etwas wäre jetzt auch nicht so ungewöhnlich und das eigentlich mal gefixte Probleme nach Updates evtl. wieder auftauchen sind auch keine Seltenheit. Bei dem e1000 “Bug” ist das auch nicht anders. Der ist - je nach Kernel - mal da und dann mal wieder weg.
Da der AX88179 ja auch nur 1000 Mbps macht/kann und es somit im LAN keinen Unterschied macht ob Du jetzt den, oder die int. Intel NIC von der Kiste nutzt, würde ich einfach die int. Intel NIC wieder aktivieren, dann die ja bekannte Einstellung unter Proxmox dafür eingeben
und dann die Intel NIC wieder nutzen.
Dann kannst Du ja in Ruhe abwarten ob ggf. in nächster Zeit irgendwelche Probleme mit dem AX88179 gemeldet werden und wenn ja ob es dafür eine Lösung gibt.
Eine Intel I350-T4 habe ich hier auch noch liegen und ursprünglich war die auch mal in meiner Proxmox Kiste drin. Ja dieser e1000 Bug tauchte bei der nicht auf, aber da ich dann für die 4-Ports keine Verwendung mehr hatte, habe ich mir lieber eine Realtek 2.5GbE PCI NIC eingebaut.
Kostete irgendwas um die € 20 und die macht jetzt seit ca. 2 Jahren auch keine Probleme mit Proxmox. BTW: Die in meiner Fujitsu Proxmox Kiste verbaute I-219-LM ist von dem e1000 auch nicht betroffen. Wobei das aber eben auch von der Revision der I219-LM abhängt.
Edit: Weil ich das vergessen hatte.
Wer auch immer das empfohlen hat, aber so wirklich machen irgendwelche Empfehlungen da nicht wirklich Sinn, weil das Thema NICs immer ein gewissen “Glücksspiel” ist und das weniger von dem Chip, sondern eher von der Revision des Chips abhängt und dann welche Linux Kernel Version und Treiber dann gerade welche Probleme damit hat/haben. Oder eben auch nicht.
Der RT8125 2.5GbE Chip in meiner Proxmox Kiste macht bei anderen Usern auch dann und wann mal Problem, sprich bei dem soll es immer mal wieder zu Aussetzern bei der Datenübertragung kommen. Bei der bei meiner PCI NIC verbauten Rev.05 treten diese Aussetzer aber nicht auf.
Dann habe ich hier auch noch drei USB 2,5GbE NICs von zwei unterschiedlichen Herstellern. Bei allen wird ein Realtek RTL8156 Chip verwendet. Bei einer von den dreien kommt es mit Linux und je nach verwendeten Kernel, zu diesen Aussetzern und/oder die NIC verliert nach x Stunden mal ganz kurz die Verbindung. Bei zwei anderen, wo zum Beispiel ein RTL8156B-2 v3 Chip verbaut ist und aktuell dieser R8152 Treiber
VG Jim
Vielen Dank für eure ausführlichen Antworten.
@Jim_OS Hast Du aktuell irgendwelche Updates bei Proxmox gemacht und z.B. das 9.1.x Update installiert?
Ja, das habe ich.
Ich war am überlegen, die interne wieder zu aktivieren und mit den empfohlenen Proxmox Einstellungen wieder zum laufen zu bringen.
Aber es wäre schon überlegenswert direkt eine 2,5GB Karte zu verbauen, ich habe gesehen da gibt es bei Amazon Preise von 16€ - 40€, könntest du mir eine gute empfehlen?
