Der "Lockup-Detector", der auf einigen SMP-Systemen selbst Lockups verursacht...
An sich ist es ja eine schöne Idee, die die Kernelentwickler da hatten: der auf normalen Systemen so gut wie nie benutzte NMI (Non-Maskable Interrupt, nicht ausblendbare CPU-Unterbrechungsanforderung) kann unter Linux dazu genutzt werden, "hängende" bzw. blockierte Prozesse oder auch Kernelroutinen erkennen und die Kontrolle über das System wiedergewinnen zu können. Hierzu gibt es in der Kernel-Konfiguration den Parameter "CONFIG_LOCKUP_DETECTOR", wie er zumindest in neueren Versionen seit Mitte 2011 heißt. "Umgangssprachlich" (und auch innerhalb des Kernels) kursieren für diesen Mechanismus typischerweise zwei Bezeichnungen: neben "lockup detector" wird auch "nmi watchdog" verwendet.
Der normalerweise nur für kritische Hardwarezustände wie Speicherfehler (Parität/ECC) oder Reset-Anforderungen verwendete NMI wird in diesem Fall mit einem Timer verknüpft, um in gewissen Abständen die CPU bei wirklich jeder irgendwie denkbaren Aufgabe zu unterbrechen. Während dieser Unterbrechung werden dann gewisse Prüfungen durchgeführt, um festzustellen, ob im Vergleich zur vorigen Unterbrechung eine echte "Tätigkeit" oder nur ein Festhängen des Prozessors vorliegt.
An sich hört sich das gut an - leider hat es aber zwei eklatante Nachteile:
- im Gegensatz zur Dokumentation auf kernel.org hält sich der Mechanismus nicht daran, erst beim Setzen des Bootparameters "nmi_watchdog=1" aktiv zu werden, sondern er ist mindestens dann automatisch präsent, wenn der Kernel entweder einen (lokalen) APIC beim Starten entdeckt oder ein SMP-System erkannt wird (was wiederum die Existenz eines APIC bedeutet, welcher als Timer und Interruptquelle benötigt wird)
- zumindest auf meinen SMP-Serversystemen hat dieser "Lockup-Detector" zu erheblichen Problemen geführt, die kaum diagnostizierbar sind und von ihrer Art praktisch wie ein Hardware-Defekt erscheinen!
Fehlerbild
Folgendes habe ich erlebt: nach mehreren Tagen Dauerbetrieb - der Zeitraum variierte zwischen typischerweise etwa acht Tagen bis hinunter zu nur einem Tag - reagierte der Rechner nicht mehr. Es war aber kein typischer Absturz oder ähnliches: auffällig war, daß die vorhandenen Diagnose-LEDs für die Aktivität der einzelnen Prozessoren sehr auffällige "Blinkmuster" zeigten: bei den ältesten auffälligen Kerneln (um etwa 2.6.38 herum) war es ein gleichmäßiges gedimmtes Leuchten aller LEDs, was bedeutet daß alle CPUs sich offenbar gegenseitig blockiert hatten. Bei späteren Kerneln (3.x) veränderte sich dieses Bild etwas und bekam mehr Variationen, die sonstigen Eigenschaften der Ausfälle änderten sich aber nicht. Es traf stets auch mehrere unterschiedliche Rechnertypen, in meinem Fall sowohl IBM Netfinity 5000 (Dual-P3) wie auch IBM Netfinity 7000 M10 (Quad-P3-Xeon).
Warum begann es bei mir mit Kernel 2.6.38? Da ich Debian nutze und in den vorkompilierten Kerneln vor 2.6.38 der NMI-Watchdog nicht hineinkonfiguriert war.
Wie stelle ich fest, ob der Lockup-Detector/NMI-Watchdog aktiv ist?
Diese Untersuchung ist recht einfach: es genügt, den Inhalt von /proc/interrupts ausgeben zu lassen, ggf. mehrfach mit einigen Sekunden Abstand dazwischen.
- ein System ohne Watchdog zeigt in der Zeile "NMI" eine Anzahl im Bereich von 0 oder 1 bis hin zu maximal einer sehr niedrigen Zahl an Ereignissen, die sich auch bei mehrfacher Ausgabe der Liste nicht ändert
- ein System mit aktivem Watchdog zeigt in der Zeile "NMI" eine normale (höhere) Anzahl an Ereignissen, die zudem regelmäßig ansteigt
Workaround bzw. Lösung des Problems
Ob es mittlerweile in den aktuellsten Kernelversionen eine Lösung für dieses Problem gibt, kann ich leider nicht sagen, da der folgende Workaround mittlerweile meine Dauerlösung geworden ist und ich meine Systeme zur produktiven Nutzung und nicht für das Erlebnis sporadischer Abstürze benötige.
Die Lösung ist einfach: es muß nur der Bootparameter "nowatchdog" an den Kernel übergeben bzw. in die Bootloader-Konfiguration eingetragen werden.
Weitere Informationen
Die folgenden Links führen zu meinen Original-Bugreports, die ich sowohl an Debian wie auch an den Bugzilla-Service von kernel.org übermittelt habe, auf die aber leider kaum eine Reaktion erfolgt bzw. erfolgt ist: