Kernel-Watchdog erkennt CPU-Softlockup · Linux Fix Lab

Symptome und Geltungsbereich

Desktop oder Dienst reagieren über längere Zeit nicht.
Der Kernel nennt festhängende CPU und Aufgabe in einer Softlockup-Warnung.

Betroffene Umgebung

Linux mit aktivem Softlockup-Detektor, auf Hardware oder in VMs. Das Zeitlimit ist einstellbar und kein Leistungstest.

Erkennbare Meldungen (synthetische Beispiele)

watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [worker:440]

Ausführungsspuren und Virtualisierungskontext prüfen; ein Softlockup unterscheidet sich von GPU-Ring-Zeitüberschreitung und Interrupt-Hardlockup.

Mögliche Ursachen

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

Ein langer nicht unterbrechbarer Kernelpfad, eine Treiberschleife oder fehlende Scheduling-Zeit können den Watchdog verzögern.
Eine pausierte oder lange nicht eingeplante VM sowie geänderte Watchdog-Zeitlimits können zeitlich irreführende Hinweise liefern.

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

Watchdog- und Stack-Zeilen lesen; Administratorzugriff kann nötig sein. Für einen Bericht zusätzlich den umgebenden ungefilterten Verlauf behalten.

journalctl -b -k --no-pager --grep='soft lockup|watchdog|Call Trace|RIP:'

Ergebnis einordnen: Wiederholte Blockaden im gleichen Ausführungspfad sind aussagekräftiger als einzelne Warnungen nach einer VM-Pause. Die genannte Aufgabe kann betroffen statt verantwortlich sein.

Prüfschritt 2

Zeitlimit und Panic-Richtlinie ohne Wertzuweisung lesen. Verfügbarkeit hängt von der Kernel-Konfiguration ab.

sysctl kernel.watchdog_thresh kernel.softlockup_panic

Ergebnis einordnen: Ein ungewöhnlich niedriges Zeitlimit kann frühere Meldungen erklären; Erhöhen würde eine wiederkehrende Blockade jedoch verstecken. Die Panic-Richtlinie erklärt automatische Neustarts.

Nächste Schritte nach Befund

Ermittelten Tracing- oder Konsolenaufwand reduzieren

Tritt der Vorfall nur bei starkem Tracing oder sehr ausführlicher Ausgabe auf einer langsamen Konsole auf, diese optionale Instrumentierung dokumentiert abschalten und Minimal-Arbeitslast vergleichen. Stack und Pausendauer gegenüberstellen.

Vorsicht: Normale Kernel-Fehlerprotokollierung und Watchdog-Erkennung aktiv halten. Notwendige Überwachung nicht lediglich wegen störender Warnungen stoppen.

Wiederherstellung / Rücknahme: Dokumentiertes Tracing- oder Konsolenprofil bei Bedarf für einen gezielten weiteren Mitschnitt wiederherstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Kernel oder VM-Scheduling-Kontext vergleichen

Bei wiederholter Hardware-Spur einen unterstützten älteren Kernel und passende paketierte Korrektur vergleichen. Bei Warnungen nur nach VM-Pause oder Migration zuerst Host-Zeitlinie und Scheduling statt Gast-Kernelrichtlinie prüfen.

Vorsicht: Arbeitslasten und Hardware-Einstellungen gleich halten; zerstörende Wiederholungstests bei fehlender sauberer Wiederherstellung vermeiden.

Wiederherstellung / Rücknahme: Bei Verschlechterung ursprünglichen unterstützten Starteintrag oder vorheriges VM-Scheduling-Profil wiederherstellen.