XID 119 GSP-RPC-Timeout und XID 120 GSP-Fehler auf NVIDIA-GPUs: Ursachen und Lösungen

Was XID 119 und XID 120 bedeuten

XID 119 ist ein GSP-RPC-Timeout, XID 120 ein GSP-Fehler: Der NVIDIA-Treiber protokolliert sie, wenn Code auf dem GPU System Processor, einem kleinen Prozessor auf der GPU, scheitert oder eine Anfrage nicht rechtzeitig beantwortet. NVIDIAs XID-Katalog gibt beiden Codes dieselben Maßnahmen: sofort die GPU zurücksetzen, danach die Software untersuchen, in der Praxis also den Treiber. Bleibt der Fehler, kann ein GPU-Reset oder ein Aus- und Einschalten des Knotens nötig sein; kommt er danach wieder, verweist NVIDIA auf seine GPU Debug Guidelines.

Der Katalog, zuletzt aktualisiert am 9. September 2026, nutzt für beide Codes denselben Auslösetext. Sie „may be logged when an error occurs in code running on the GSP core of the GPU and/or a timeout occurs while waiting for the GSP core of the GPU to respond to an RPC message“. Ein RPC ist hier eine Anfrage des Treibers auf dem Host an die Firmware auf der GPU. 119 bedeutet also, dass der Treiber gewartet und aufgegeben hat, 120, dass die Firmware selbst einen Fehler gemeldet hat. Beide stoppen die GPU für die laufende Arbeit.

NVIDIA XID Catalog, „Analyzing Xid Errors with the Xid Catalog“, Stand 9. September 2026, gelesen am 24. Oktober 2026. Die Spalten zur Anwendbarkeit markieren beide Codes für A100, H100, B100 und GB200.

Die letzte Spalte ist für die Automatisierung wichtig. XID 154, „GPU Recovery Action Changed“, fasst die Recovery Action zusammen, die andere Codes verlangen. Der Katalog nennt dort für 120 den Treiber R565 und für 119 nichts. Nach unserer Lesart kann auf einem aktuellen Treiber nach einem 120 also eine 154-Zeile mit der Recovery Action folgen, nach einem 119 nicht. Unser Leitfaden zu XID 154 und 62, GPU-Reset oder Neustart beschreibt, wie Sie auf diese Zeile reagieren, und die Übersicht der NVIDIA-XID-Fehlercodes listet die übrigen Codes. Dieser Artikel behandelt nur 119 und 120.

Was der GSP macht und woher seine Firmware kommt

NVIDIAs README zum Linux-Treiber beschreibt den GSP in einem Satz: „Some GPUs include a GPU System Processor (GSP) which can be used to offload GPU initialization and management tasks.“ Der Treiber nutzt die GSP-Firmware „by default for all Turing and later GPUs“. Alle Karten, die wir liefern, fallen darunter: L4 und L40S (Ada), H200 NVL (Hopper) und die RTX PRO Blackwell, einschließlich der RTX PRO 6000 Server Edition.

Die Firmware gehört zum Treiber, nicht zur Karte. Laut README des Treibers 575.64 liegen die Dateien in /lib/firmware/nvidia/575.64/, benannt als gsp_*.bin nach den GPU-Architekturen, für die sie gelten. Die Beispielausgabe zeigt die GSP-Firmware-Version gleich der Treiberversion. Ein Treiberupdate ersetzt also auch die GSP-Firmware, während das VBIOS auf der Karte unverändert bleibt. Zwei Stellen zeigen, welche Firmware läuft:

• nvidia-smi -q -d GSP_FIRMWARE_VERSION zeigt je GPU das Feld „GSP Firmware Version“; eine Versionsnummer bedeutet, dass GSP aktiv ist, „N/A“, dass er abgeschaltet ist.
• Unter /proc/driver/nvidia/gpus/ und der PCI-Bus-ID der GPU enthält die Datei information eine Zeile „GSP Firmware“.

Auf einem Server mit gemischten Treiberständen, etwa nach einem abgebrochenen Update, ist das der schnellste Test, ob jede GPU die Firmware des Treibers nutzt, den Sie für geladen halten.

GSP abschalten ist bei Blackwell keine Option

Dasselbe README dokumentiert einen Schalter: „The driver can be forced to disable use of GSP firmware by setting the kernel module parameter NVreg_EnableGpuFirmware=0.“ Auf Blackwell hat dieser Parameter keine unterstützte Verwendung. Das README der offenen GPU-Kernelmodule von NVIDIA (Version 615.71.09) sagt, die Module „must be used with GSP firmware and user-space NVIDIA GPU driver components“. NVIDIAs Blogbeitrag vom 17. Juli 2024 zum Wechsel auf offene Module schreibt: „For cutting-edge platforms such as NVIDIA Grace Hopper or NVIDIA Blackwell, you must use the open-source GPU kernel modules. The proprietary drivers are unsupported on these platforms.“

Zusammen heißt das: Die RTX PRO 6000 in allen drei Editionen, die RTX PRO 4500 Server Edition und die übrigen RTX PRO Blackwell laufen immer mit GSP. Für H200 NVL, L40S und L4 gibt es die proprietäre Variante in den Zweigen R580 und R595 noch, ab R615 liefern NVIDIAs Pakete aber nur noch die offenen Module, wie unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt. GSP auf diesen Karten abzuschalten heißt also, auf eine auslaufende Modulvariante zu wechseln. Wir würden das nur nutzen, wenn der Support des Systemherstellers oder von NVIDIA es in einem Fall als Test verlangt, nie als Lösung für eine produktive Flotte. Server, die wir nach Auftrag bauen, kommen auf Wunsch mit Betriebssystem und NVIDIA-Treiber vorinstalliert; nennen Sie uns Zweig und Modulvariante, dann kommt der Server so eingerichtet an.

README von NVIDIA open-gpu-kernel-modules (615.71.09) und NVIDIA-Technikblog vom 17. Juli 2024, gelesen am 24. Oktober 2026; Paketierung ab R615 laut Release Notes von R615, wie in unserem Treiberleitfaden zitiert. Die letzte Spalte ist unsere Lesart dieser Aussagen.

Erste Schritte bei XID 119 oder 120

Die Sofortmaßnahme des Katalogs ist ein GPU-Reset, und das nvidia-smi-Handbuch nennt seine Grenzen: nvidia-smi -r „Requires root“, es „can't be any applications using these devices“, ein Reset gelingt nicht in jedem Fall, und „It is not recommended for production environments at this time“. Behandeln Sie den Reset deshalb als Wartungsschritt an einer GPU ohne Last.

1. Notieren Sie die XID-Zeile, die Uhrzeit und die PCI-Adresse darin. Die Adresse gehört zum Steckplatz; unser Leitfaden zum Finden der defekten GPU über Bus-ID, Slot und Seriennummer macht daraus eine Karte und eine Seriennummer.
2. Prüfen Sie die Zeilen davor und danach. Eine 154-Zeile nennt die Recovery Action, ein 62 weist auf einen angehaltenen internen Mikrocontroller hin, und ein 79 bedeutet, dass die GPU vom Bus gefallen ist; dazu gibt es einen eigenen Artikel zu XID 79.
3. Führen Sie nvidia-bug-report.sh vor jedem Reset aus, damit die Spuren erhalten bleiben.
4. Nehmen Sie die GPU aus dem Betrieb: aus dem Scheduler oder dem Load Balancer nehmen und die Prozesse darauf beenden.
5. Setzen Sie die GPU mit nvidia-smi -r -i und ihrer Bus-ID zurück. Ist sie danach nicht gesund, soll laut Handbuch „a complete reset“ durch „power cycling the node“ folgen.
6. Kommt 119 oder 120 nach dem Aus- und Einschalten zurück, folgen Sie NVIDIAs GPU Debug Guidelines und eröffnen einen Fall beim Systemhersteller.

Für GPUs mit NVLink, etwa in einem H200-NVL-Server mit Brücken, sagt das Handbuch, dass sich solche GPUs ab der Ampere-Architektur „can be individually reset“. In einer virtuellen Maschine gilt laut NVIDIAs Debug Guidelines: „GPU reset not supported in VMs. Restart the VM.“

Die Treiberseite: Zweig, Release Notes und ein behobener Absturz

INVESTIGATE_SW führt zuerst zum Treiber, denn die GSP-Firmware und der Code, der mit ihr spricht, stammen beide aus dem Treiberpaket. Prüfen Sie drei Dinge.

• Den Zweig. Für den Produktivbetrieb R580 (Long Term Support Branch) oder R595 (Production Branch), wie in NVIDIAs Treibertabelle vom 9. September 2026 aufgeführt.
• Das Release. Treiber 580.196.07 vom 21. Oktober 2026 nennt als behobenen Fehler: „Fixed a race condition between GPU event notification and subdevice teardown that could cause a system crash. On Linux, the issue was observed following a GSP RPC timeout.“ Die Korrektur beseitigt einen Absturz nach einem 119, nicht den Timeout selbst. Hat ein 119 auf einem R580-Host den ganzen Knoten mitgerissen, ist dieses Release der erste Schritt.
• Das VBIOS vor dem nächsten Update. Die Release Notes von 595.112.07 vom 22. Oktober 2026 enthalten ein bekanntes Problem für Hopper: Der Treiber „will fail to initialize on systems with Hopper GPUs subrevision = 3 and VBIOS versions older than 96.00.68.00.xx“, und NVIDIA verlangt vor dem Update VBIOS 96.00.68.00.xx oder neuer. Lesen Sie das VBIOS jeder H200 NVL mit nvidia-smi aus, bevor Sie einen solchen Host auf R595 bringen.

Release Notes der NVIDIA-Rechenzentrumstreiber 580.196.07 und 595.112.07, gelesen am 24. Oktober 2026; NVIDIA-Knowledge-Base-Artikel zu nützlichen nvidia-smi-Abfragen (Felder gpu_name, gpu_bus_id, vbios_version); Pinning wie in unserem Treiberleitfaden beschrieben.

Keine der beiden Release Notes nennt ein bekanntes Problem zu 119 oder 120. Wiederholt sich der Code auf dem aktuellen Release eines unterstützten Zweigs, liegt die Ursache außerhalb der bekannten Treiberprobleme, und der Fall beim Systemhersteller ist der nächste Schritt. Wir bauen Server mit RTX PRO 6000 Server Edition und H200 NVL und installieren den Treiberzweig, den Ihre Flotte nutzt; teilen Sie uns Zweig und Karten mit, und unser Team antwortet mit einer Konfiguration auf diesem Zweig.

vBIOS und Server-Firmware kommen über den Serverhersteller

Das VBIOS sitzt auf der Karte, BIOS und BMC-Firmware im Server. NVIDIAs Hopper-Hinweis oben zeigt, dass beide zum Treiber passen müssen. Für Karten in einem Rack-Server beziehen Sie VBIOS-Updates von den Supportseiten des Serverherstellers für genau dieses Modell, weil der Hersteller die Kartenfirmware mit seinem BIOS und seiner Slotbelegung freigibt; unser Leitfaden zu Firmware-Updates für vBIOS, BMC und BIOS beschreibt die Reihenfolge.

Unser Leitfaden zum Abnahmetest hält bei der Lieferung VBIOS- und GSP-Firmware-Versionen jeder Karte fest. Diese Aufzeichnung zahlt sich hier aus: Meldet eine von acht Karten 119 und weicht ihr VBIOS von den anderen sieben ab, ist die Version die erste Spur. Gleiche Karten aus einer Lieferung sollten gleiche Versionen melden.

Persistence Mode und Überwachung von GSP-Fehlern

Laut nvidia-smi-Handbuch gilt mit aktivem Persistence Mode: „the NVIDIA driver remains loaded even when no active clients, such as X11 or nvidia-smi, exist“, und nach jedem Neustart steht der mit nvidia-smi -pm gesetzte Modus wieder auf „Disabled“. Auf einem GPU-Server sollte der Treiber geladen bleiben; prüfen Sie daher nach einem Neustart, ob der Persistence Mode wieder aktiv ist. NVIDIA nennt den Persistence Mode weder als Ursache noch als Lösung für 119 oder 120; er gehört auf die Checkliste, weil ein Neustart während des Vorfalls ihn auf „Disabled“ zurücksetzt.

Für Alarme stellt die Standard-Felddatei von dcgm-exporter DCGM_FI_DEV_XID_ERRORS bereit, den „Value of the last XID error encountered“, und lässt den Zähler DCGM_EXP_XID_ERRORS_TOTAL auskommentiert. Ein einzelner 119 zwischen zwei anderen Codes kann aus dieser Anzeige verschwinden; aktivieren Sie daher den Zähler oder alarmieren Sie aus dem Kernel-Log. Unser Leitfaden zum Monitoring von GPU-Servern mit DCGM listet die Felder.

Wann ein GSP-Fehler auf die Karte zeigt

Der Katalog ordnet 119 und 120 der Software zu; ein einzelnes Auftreten, das ein Reset beseitigt, ist also Sache des Treibers. Drei Muster verschieben den Verdacht nach unserer Lesart von NVIDIAs Maßnahmen zur Hardware:

• der Code kehrt nach vollständigem Aus- und Einschalten auf einem aktuellen Treiber eines unterstützten Zweigs zurück;
• er folgt nach einem Slottausch der Karte und nicht dem Steckplatz, wie in unserem Artikel zu XID 79 beschrieben;
• er tritt zusammen mit Speicher-, PCIe- oder NVLink-Codes auf derselben GPU auf, deren eigene Maßnahmen dann gelten.

Führen Sie in jedem dieser Fälle dcgmi diag -r 3 auf der betroffenen GPU aus, bevor der Fall eröffnet wird, und vergleichen Sie mit den Werten aus dem Abnahmetest.

Was ein Supportfall enthalten sollte

NVIDIAs GPU Debug Guidelines (Stand 4. Oktober 2026) listen, was ein Bericht enthalten soll, und schließen mit „Submit a ticket to your system vendor“. Bei GSP-Fehlern kommen die Versionen dazu, die die Softwareseite bestimmen.

NVIDIA GPU Debug Guidelines, GPU Node Triage, „Reporting a GPU Issue“, gelesen am 24. Oktober 2026; Zeilen mit „unsere Empfehlung“ stammen von uns.

Die Guidelines nennen NVIDIAs Felddiagnose „the authoritative and comprehensive NVIDIA tool for determining the health of GPUs“ und schreiben, sie sei „usually required before an RMA can be started“; wann und wie sie läuft, sagt der Systemhersteller. Für GPUs, die Sie bei uns kaufen, wird die Herstellergarantie über uns abgewickelt; senden Sie uns die XID-Zeilen und die Versionen oben, wir antworten innerhalb eines Werktages.

FAQ