Netzwerk-Sendewarteschlange oder Hardware hängt · Linux Fix Lab

Symptome und Geltungsbereich

Netzverkehr stoppt bis zum Treiber-Reset oder Neustart.
Der Kernel meldet NETDEV WATCHDOG oder einen e1000e-Hardware-Unit-Hang.

Betroffene Umgebung

Ethernet- oder andere netdev-Treiber mit Sendewarteschlangen; zusätzliche Hardware-Hang-Signatur gilt speziell für Intel e1000e.

Erkennbare Meldungen (synthetische Beispiele)

kernel: NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 5260 ms

Benachbarte Schnittstellen- und Treiberdetails erhalten; Formulierung variiert nach Kernel und benennt keine einzelne Hardwareursache.

e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang:

Folgende Ring-/PHY-/PCI-Details und gerätespezifische Hinweise vor Wahl einer Abhilfe lesen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Die Sendewarteschlange hat im Watchdog-Fenster keinen Fortschritt erzielt; Treiber, Gerät, Firmware, Interruptverarbeitung oder Linkprobleme können beteiligt sein.
Unpassende treiberspezifische Optimierungsoption oder Kernel-Regression können beitragen; der Watchdog allein wählt jedoch keine Abhilfe aus.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

IFACE durch die Watchdog-Schnittstelle ersetzen. Treiber, Buskennung und gemeldete Firmware-Version ohne Kartenreset lesen.

ethtool -i IFACE

Ergebnis einordnen: Bei Abhilfen den tatsächlichen Treibernamen nutzen. Leeres firmware-version-Feld bedeutet allein keine fehlende Firmware; PCI-Kennung und laufende Kernelversion festhalten.

Prüfschritt 2

Treiberereignisse um den Stillstand lesen; Journalrechte können nötig sein. Watchdog-Zeile, vorherige Link-/PCI-Fehler und treiberspezifische Rettungshinweise erhalten.

journalctl -k -b --no-pager -n 400

Ergebnis einordnen: Watchdog bezeichnet fehlenden Sendefortschritt statt DNS-Timeout. e1000e-Hardware-Hang-Details helfen beim Treiberbericht; wiederholte Resets beweisen keinen physischen Kartendefekt.

Nächste Schritte nach Befund

Unterstützten Kernel und Treiber vergleichen

Wenn der Hang nach Kernel-Update begann, einen bereits installierten früheren unterstützten Kernel starten und dieselbe Karte, Verbindung und begrenzte Last vergleichen. Bei bleibendem Fehler Distributionshinweise zu Treiber/Firmware mit genauer Geräte-ID und Hang-Details prüfen.

Vorsicht: Beide Startoptionen und lokalen Zugang erhalten. Keinen unbeteiligten externen Treiber laden und einzige Fernzugangskarte nicht während aktiver Sitzung entladen.

Wiederherstellung / Rücknahme: Über das Startmenü zum funktionierenden Kernel zurückkehren und dokumentierte Treiberoptionen wiederherstellen, wenn eine vorgeschlagene Aktualisierung den Zugang verschlechtert.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Bestätigte Treiberoptimierung zurücknehmen

Wenn e1000e gebunden ist und eine gespeicherte Moduloption RxIntDelay über den dokumentierten Standard null setzt, nur diese Option entfernen und nach kontrolliertem Neustart vergleichen. Alternativ eine vom genauen Treiber-/Hardware-Log oder offizieller Dokumentation genannte Abhilfe einzeln prüfen.

Vorsicht: Dieser Empfangsverzögerungshinweis gilt für e1000e, nicht jede Karte. Vorige Optionen dokumentieren und Rettungskonsole behalten; pauschales Abschalten von Offload/Energiesparen kann Befunde verdecken und Leistung senken.

Wiederherstellung / Rücknahme: Gesicherte einzelne Option bei fehlendem Nutzen oder neuen Problemen wiederherstellen und zum Kernel mit funktionierender Verbindung zurückkehren.