NVIDIAs Open-Source-Kernel-Treiber stößt auf eine 66-Tage-Barriere: Eine eingehende Analyse des B200-NVLink-Hangs

Der NVIDIA Open-Source-Kerneltreiber, ein Projekt, das in der Linux-Community zunehmend an Bedeutung gewonnen hat, ist auf einen erheblichen und merkwürdig präzisen Fehlermodus gestoßen. Nutzer, die den Treiber auf den neuesten B200-GPUs ausführen, berichten, dass nvidia-smi und jede Anwendung, die auf NVLink-Kommunikation angewiesen ist, nach genau 66 Tagen und 12 Stunden Systemlaufzeit nicht mehr reagieren.

Das Problem, dokumentiert in GitHub issue #971 im offiziellen NVIDIA-Repository, wurde erstmals Ende 2025 von dem Nutzer zheng199512 gemeldet. Der Bericht beschreibt ein System mit dem Treiber 570.133.20 auf einer NVIDIA-B200-GPU mit Kernel 6.6.0. Nach dem kritischen Laufzeit-Schwellwert hängt der Befehl nvidia-smi unbegrenzt. Die Systemprotokolle (dmesg) zeigen eine Kaskade von NVLink-bezogenen Fehlern, insbesondere knvlinkUpdatePostRxDetectLinkMask_IMPL: Failed to update Rx Detect Link mask! und knvlinkDiscoverPostRxDetLinks_GH100: Getting peer's postRxDetLinkMask failed!. Diese Fehler deuten auf einen Ausfall der Fähigkeit der GPU hin, ihre Hochgeschwindigkeits-Verbindungen zu verwalten, die für die Multi-GPU-Kommunikation in Rechenzentren und KI-Clustern entscheidend sind.

Das ist kein isolierter Vorfall. Die Community meldete schnell ähnliche Erfahrungen. Der Nutzer t-shunsuke01 berichtete über dasselbe Verhalten auf einer B200 mit Ubuntu 24.04 und den Treiberversionen 580.82.07 und 580.105.08, was bestätigt, dass der Fehler über mehrere Treiberzweige hinweg bestehen bleibt. Ein anderer Nutzer, lmacken, lieferte einen konkreten Zeitrahmen: Zwei B200s, beide am 31. Oktober gestartet, fielen am 6. Januar aus, was mit der Laufzeit von etwa 67 Tagen übereinstimmt. Der alarmierendste Bericht kam von jquesnelle, der den Ausfall in einem B200-Cluster mit 256 GPUs erlebte, was zu weitreichenden Job-Fehlschlägen führte.

Der NVIDIA-Ingenieur mtijanic bestätigte das Problem und erklärte, dass es die 570er-Serie betrifft und auf der 580er-Serie reproduziert wurde. Das Problem wurde unter den Bug-IDs 5746052 und 5607938 an das interne NVLink-Team eskaliert. Die offizielle Antwort lautet zwar, dass an einer Lösung gearbeitet wird, ein Zeitplan wurde jedoch nicht genannt.

Das 66-Tage-Rätsel: Ein Jiffies-Overflow?

Die Präzision des Ausfallzeitpunkts, 66 Tage und 12 Stunden, führte in der Community zu Spekulationen über die Ursache. Der Nutzer ma-ts untersuchte das Problem und stellte eine überzeugende Theorie auf: einen jiffies-basierten Zeitüberlauf. Der Linux-Kernel verwendet eine Variable namens jiffies, um System-Ticks zu zählen. Die Frequenz dieser Ticks wird durch die Kernel-Konfiguration CONFIG_HZ festgelegt. Bei einer häufigen Einstellung von CONFIG_HZ=750 läuft der 32-Bit-jiffies-Zähler nach etwa 66 Tagen und 12 Stunden wieder auf null zurück. Das ist ein klassisches Integer-Overflow-Problem.

Wenn die NVLink-Zustandsmaschine des NVIDIA-Treibers für Zeitberechnungen oder Timeouts auf jiffies angewiesen ist, könnte das Erreichen dieses Wrap-around-Punkts die Logik zum Scheitern bringen und zu den beobachteten Ausfällen führen. Diese Theorie wird durch die Tatsache gestützt, dass sich die Fehler auf die Erkennung von NVLink-Verbindungen und das Aktualisieren von Masken beziehen, also Prozesse, die vermutlich zeitgesteuerte Abläufe beinhalten.

In der Diskussion wurde ein Pull Request erwähnt, PR #1014. Dieser PR schlägt vor, von jiffies auf ktime_get_raw_ts64() umzusteigen, eine robustere Zeitfunktion, die 64-Bit-Nanosekunden verwendet und nicht für diesen speziellen Überlauf anfällig ist. Das passt exakt zur vorgeschlagenen Diagnose.

Auswirkungen auf die Community und Gegenpositionen

Die Auswirkungen sind erheblich für alle, die B200-Installationen im großen Maßstab betreiben. Der Fehler betrifft nicht nur Überwachungstools wie nvidia-smi; er beeinträchtigt jede Anwendung, die NVLink für GPU-zu-GPU-Kommunikation nutzt. Bei AI- und HPC-Workloads, in denen die Koordination mehrerer GPUs Standard ist, kann dieser Bug ganze Cluster zum Stillstand bringen und einen vollständigen Neustart des Systems erforderlich machen, um die Umgebung wiederherzustellen.

Allerdings ist der Umfang zu beachten. Das Problem scheint spezifisch für den Open-Source-Kerneltreiber (NVIDIA/open-gpu-kernel-modules) zu sein. Der Melder bestätigte, dass dasselbe Problem beim proprietären Treiber derselben Version nicht auftritt. Das legt nahe, dass der Fehler während des Portierungsprozesses eingeführt wurde oder ein spezifischer Mangel in der Zeitlogik der Open-Source-Implementierung ist.

Darüber hinaus scheint der Fehler an bestimmte Hardware (B200) und die NVLink-Infrastruktur gebunden zu sein. Systeme mit einzelnen GPUs oder ohne NVLink-Nutzung könnten den Hänger nicht erleben, auch wenn die zugrunde liegende Instabilität des Treibers weiterhin ein Risiko darstellen könnte. Die interne Verfolgung des Problems durch NVIDIA unter mehreren Bug-IDs zeigt, dass es sich innerhalb ihrer Entwicklungsteams um ein bekanntes und ernstes Problem handelt.

Worauf man achten sollte

Für Administratoren von B200-Clustern, die den Open-Source-Treiber verwenden, gibt es vorerst einige Optionen:

1. Neustarts planen: Einen Wartungsplan einführen, um Systeme vor der 66-Tage-Marke neu zu starten. Das ist zwar nur eine temporäre Umgehung, sorgt aber für Stabilität.
2. Protokolle überwachen: dmesg auf die typischen NVLink-Fehler beobachten. Frühwarnungen könnten ein Zeitfenster schaffen, um vor einem vollständigen Hänger zu handeln.
3. Den proprietären Treiber in Betracht ziehen: Wenn Stabilität oberste Priorität hat und die Funktionen des Open-Source-Treibers nicht kritisch sind, kann ein Wechsel zurück zum proprietären Treiber eine vernünftige Wahl sein, bis eine Korrektur veröffentlicht wird.

Die Community diskutiert aktiv mögliche Patches und Workarounds. Die vorgeschlagene Lösung in PR #1014 ist ein starker Kandidat, muss aber noch validiert und in eine stabile Treiberversion integriert werden. Bis NVIDIA das Problem offiziell behebt, bleibt diese 66-Tage-Zeitbombe ein kritischer Faktor für jede Bereitstellung von NVIDIAs Open-Source-Treiber auf GPUs der Blackwell-Architektur.