NVIDIA XID-Fehlercodes im XID-Katalog: was 13, 31, 48, 74, 79, 94, 95 und 119 bedeuten

Was ein NVIDIA-XID-Fehler ist

Ein XID ist nach NVIDIAs Worten „ein Fehlerbericht des NVIDIA-Treibers, der in das Kernel-Log oder Ereignisprotokoll des Betriebssystems ausgegeben wird“. Unter Linux ist jeder XID eine Zeile, die NVRM: Xid, die PCI-Adresse der GPU, die Fehlernummer und fehlerspezifische Daten enthält. NVIDIAs XID-Katalog, aktualisiert am 9. September 2026, nennt für jeden Code die Auslösebedingungen, eine Sofortmaßnahme und eine Maßnahme zur Untersuchung. Die Meldungen „können auf ein Hardwareproblem, ein Problem der NVIDIA-Software oder ein Problem der Benutzeranwendung hinweisen“, und der Code zeigt, wo Sie zuerst suchen.

Der Katalog deckt GPUs ab Ampere ab, „einschließlich GPUs im PCIe-Formfaktor“, und ist auch als Tabellendatei Xid-Catalog.xlsx veröffentlicht. Seine Spalten zur Anwendbarkeit nennen die A100, H100, B100 und GB200. Die H200 NVL ist wie die H100 eine Hopper-GPU. Die L40S, die L4 und die RTX-Karten werden dort nicht genannt, fallen als Ada- und Blackwell-GPUs aber in den Geltungsbereich des Katalogs, außer bei Codes, die von einer Funktion abhängen, die der Karte fehlt, etwa NVLink oder Error Containment.

Liste der XID-Fehlercodes: Bedeutung und NVIDIAs Maßnahme

Die Tabelle führt die Codes, denen Betreiber von PCIe-GPU-Servern am häufigsten begegnen, mit NVIDIAs Maßnahmenkategorien, den Resolution Buckets.

NVIDIA XID Catalog, „Analyzing Xid Errors with the Xid Catalog“, aktualisiert am 9. September 2026, und seine PDF-Ausgabe (Release 615); die Spalte zur Ursache ist unsere Kurzform von NVIDIAs Auslösebedingungen, die Namen der Maßnahmen sind die von NVIDIA.

Die PDF-Ausgabe des Katalogs definiert die Buckets. RESTART_APP bedeutet „Die Anwendung sollte neu gestartet werden“, RESTART_BM „Bare Metal neu starten, das System sollte neu gestartet werden“ und IGNORE „Keine Maßnahme erforderlich“. Für die Möglichkeiten und Grenzen eines Resets verweist RESET_GPU auf NVIDIAs GPU Debug Guidelines, aktualisiert am 4. Oktober 2026. Zu XID 79 schreibt dieser Leitfaden „Leeren und siehe ‚Reporting a GPU Issue‘“, und für die WORKFLOW-Buckets gibt er Schritte je Code an, denen die folgenden Abschnitte folgen. Außerdem weist er an, 61 und 62 zu melden und die GPU zurückzusetzen, während der Katalog 61 als ungenutzt markiert.

XID-Fehler im Kernel-Log finden

NVIDIA schreibt, dass die Meldungen „im Kernel-Log-Puffer protokolliert werden“, meist ins Journal und von dort nach /var/log/messages oder /var/log/syslog, und rät, mit grep nach „NVRM: Xid“ zu suchen. NVIDIAs Beispielzeile ist NVRM: Xid (0000:03:00): 14, nach einer Zeile, die die PCI-Adresse der UUID der GPU zuordnet. Auf einem Server mit vier oder acht Karten gehen Sie in dieser Reihenfolge vor.

1. Durchsuchen Sie den aktuellen Boot mit journalctl -k | grep 'NVRM: Xid' oder dmesg -T | grep 'NVRM: Xid'; frühere Boots brauchen ein persistentes Journal (journalctl -k -b -1).
2. Ordnen Sie jede PCI-Adresse mit nvidia-smi und --query-gpu=index,pci.bus_id,serial plus --format=csv einer Karte zu, damit der Fall die Seriennummer nennt und nicht einen Steckplatz.
3. Lesen Sie den Zustand der Karte mit nvidia-smi -q -d ECC,ROW_REMAPPER und nvidia-smi -q, das die GPU Recovery Action anzeigt; NVIDIA nennt dafür die Werte None, Reset, Reboot, Drain P2P und Drain and Reset.
4. Prüfen Sie, ob andere GPUs zur selben Zeit Codes protokolliert haben, denn 74 kann auf das andere Ende eines Links zeigen.
5. Führen Sie sudo nvidia-bug-report.sh vor jedem Reset oder Neustart aus; NVIDIA rät, bis zu eine Stunde einzuplanen und --safe-mode --extra-system-data anzuhängen, falls das Skript hängt.

Alarmregeln und DCGM-Felder stehen in unserem Leitfaden zum GPU-Server-Monitoring mit DCGM, und was der Management-Controller out of band meldet, steht in unserem Artikel zum Out-of-Band-Monitoring von GPUs über BMC und Redfish.

Speicherfehler: XID 48, 63, 64, 92, 94 und 95

XID 48 ist ein nicht korrigierbarer Double-Bit-ECC-Fehler, und der Katalog hält fest: „Ein GPU-Reset oder ein Neustart des Knotens ist nötig, um diesen Fehler zu beheben.“ Die GPU Debug Guidelines legen die Reihenfolge fest. Folgt 63 oder 64, gilt: „Den Knoten leeren bzw. absperren (Drain/Cordon), warten, bis alle Arbeit abgeschlossen ist, und die GPU(s) zurücksetzen, die den XID melden.“ Folgt keiner der beiden, verweist der Leitfaden auf NVIDIAs Felddiagnose, um weitere Debug-Informationen zu sammeln. XID 63 ist der Row Remapper, der eine fehlerhafte Speicherzeile durch eine Reservezeile ersetzt, und laut NVIDIA erfordert das Remapping „einen GPU-Reset, um wirksam zu werden“, und bleibt danach für die gesamte Lebensdauer der GPU bestehen. Für sich allein hat 63 in beiden Buckets IGNORE, und das Remapping wartet auf den nächsten Reset. XID 64 bedeutet, dass sich das Remapping nicht aufzeichnen ließ. Der Katalog nennt einen GPU-Reset als Sofortmaßnahme und danach einen Supportfall, während die Zeile des Leitfadens für die A100 lautet: „Der Knoten sollte sofort neu gestartet werden, da ein Fehler beim Aufzeichnen vorliegt.“ Für XID 92, eine hohe Rate von Single-Bit-Fehlern, verweist der Leitfaden ebenfalls auf die Felddiagnose.

XIDs 94 und 95 werden protokolliert, „wenn GPU-Treiber Fehler in GPUs behandeln, die Error Containment unterstützen“. Nach 94 wird nur die betroffene Anwendung neu gestartet. Nach 95 „muss die betroffene GPU zurückgesetzt werden, bevor Anwendungen neu starten können“. Mit aktiviertem MIG rät der Leitfaden, die übrigen GPU-Instanzen zu leeren und zurückzusetzen; ohne MIG „sollte“ der Knoten „sofort neu gestartet werden“.

NVIDIAs Dokument zu Speicherfehlern, aktualisiert am 9. September 2026, führt die Funktionen je Chip auf. Die H200 NVL, ein GH100, hat Error Containment und Row Remapping, deshalb können alle sechs Codes auf ihr auftreten. Die L40S, die L4 und die RTX-Ada-Karten sind Ada-Chips der Reihe AD10x nur mit Row Remapping, deshalb gelten 94 und 95 für sie nicht. Die RTX-PRO-Blackwell-Karten stehen nicht in der Tabelle, obwohl das Handbuch von nvidia-smi den Row Remapper als „auf Ampere+ verfügbar“ beschreibt; prüfen Sie also, was nvidia-smi -q -d ROW_REMAPPER auf der gelieferten Karte meldet. Für einen Row-Remapping-Fehlschlag hält NVIDIAs RMA-Richtlinie fest, dass „die RMA-Kriterien erfüllt sind, wenn das Flag für einen Row-Remapping-Fehlschlag gesetzt und durch die Felddiagnose bestätigt ist“.

NVLink-, PCIe- und GSP-Fehler: XID 74, 79, 32, 119 und 120

XID 74 ist ein NVLink-Fehler. Von den Karten, die wir liefern, hat nur die H200 NVL NVLink, über Brücken, die zwei oder vier Karten verbinden. Der Katalog schreibt, der Fehler „kann auf ein Problem mit dem Gerät am anderen Ende des Links hinweisen“; lesen Sie also die Logs jeder GPU an derselben Brücke, und ein GPU-Reset oder ein Neustart des Knotens „ist nötig, um diesen Fehler zu beheben“. Tritt er erneut auf, dekodiert der Leitfaden das erste Datenwort. Die Bits 4 oder 5 deuten auf ein wahrscheinliches ECC- oder Paritätsproblem der Hardware hin, das zu melden ist, wenn es mehr als zweimal auf demselben Link auftritt; für die Bits 8, 9, 12, 16, 17, 21, 22, 24 und 28 rät er, die mechanischen Verbindungen zu prüfen und, außer bei 21 und 22, neu zu stecken, wenn eine Behebung vor Ort nötig ist, und eine Diagnose laufen zu lassen, wenn das Problem bestehen bleibt. Ab Ampere lässt sich laut dem Handbuch von nvidia-smi eine per NVLink verbundene GPU ohne ihre Peers zurücksetzen.

XID 79 bedeutet, dass der Treiber versucht hat, die GPU über PCI Express zu erreichen, und dies nicht gelang. Laut Katalog wird der Fehler „oft durch Hardwarefehler auf dem PCI-Express-Link verursacht“, und der Katalog nennt außerdem ausfallende GPU-Hardware und andere Treiberprobleme; System-Event-Logs und PCI-Logs des Kernels „können zusätzliche Hinweise liefern“. XID 32 weist in dieselbe Richtung, da seine Fehler „vor allem Qualitätsprobleme auf PCI betreffen“. Die Prüfungen in ihrer Reihenfolge stehen in unserem Artikel zu XID 79, der GPU, die vom Bus gefallen ist.

XIDs 119 und 120 stammen vom GSP, einem Prozessor auf der GPU, mit RESET_GPU und INVESTIGATE_SW als Buckets; der Katalog ergänzt: „Ein GPU-Reset oder ein Aus- und Einschalten des Knotens kann nötig sein, wenn der Fehler bestehen bleibt.“ Bei einem Software-Bucket beginnen Sie beim Treiber: Prüfen Sie Ihren Treiberzweig und seine Release Notes, wie es unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen beschreibt. Die Spalte zu XID 154 im Katalog lautet „CUDA 12.7; GPU driver R565“ für 48, 62, 63, 64, 74, 79, 94, 95 und 120, und eine Zeile mit 154 nennt die neue Wiederherstellungsmaßnahme, etwa Node Reboot Required.

Wer bei welchem XID handelt

Die Resolution Buckets zeigen auch, wer zuerst handelt.

Buckets aus NVIDIAs XID-Katalog; erste Schritte aus NVIDIAs GPU Debug Guidelines und dem Handbuch von nvidia-smi; die Rollen sind unser Beispiel.

Für einen Reset braucht nvidia-smi -r laut dem Handbuch von nvidia-smi Root-Rechte und keine Anwendungen auf der GPU. Das Handbuch ergänzt, dass ein Reset nicht in allen Fällen sicher funktioniert und „derzeit nicht für Produktivumgebungen empfohlen wird“, und rät, den Knoten aus- und wieder einzuschalten, wenn eine GPU danach nicht intakt ist. Bevor die Karte wieder in Betrieb geht, führen Sie dcgmi diag -r 3 aus, den langen Test. NVIDIAs Triage-Leitfaden schreibt, er „sollte etwa 30 Minuten dauern“, während die DCGM-Dokumentation für Hopper-Systeme mit 4 GPUs unter 10 Minuten angibt.

Ein Beispiel sind zwei Inferenz-Server mit je vier H200 NVL an einer Vierfach-Brücke. Eine GPU protokolliert 48, gefolgt von 63. Der Betrieb sperrt diesen Server ab, lässt seine Anfragen auf den zweiten wechseln, wartet, bis die laufende Arbeit endet, und setzt die GPU zurück; die Diagnose der Stufe 3 entscheidet dann, ob der Server zurückkehrt. Nach einer 64 verlangt der Leitfaden einen sofortigen Neustart, und ein Supportfall folgt.

Wir bauen KI-Server mit diesen Karten und testen sie vor dem Versand unter Last, mit Testbericht auf Wunsch. Nennen Sie uns, wie viele Server und welche Karten Sie planen, und Konfiguration und Angebot folgen innerhalb eines Werktages.

Was Sie für den Garantiefall einsenden

NVIDIAs Triage-Leitfaden führt auf, was eine Meldung an den Hersteller enthalten sollte; ergänzen Sie, wann der Fehler auftrat und was sich geändert hat, und vergleichen Sie mit den Ergebnissen Ihres Abnahmetests und Burn-ins.

1. Betriebssystem, Treiberversion und Servermodell.
2. Die XID-Zeilen und die wichtigsten Log-Meldungen, mit PCI-Adresse, Seriennummer und Steckplatz jeder Karte.
3. Eine vollständige Auflistung des Logs, aus dem diese Zeilen stammen, und die bereits unternommenen Debug-Schritte.
4. Die Datei nvidia-bug-report.log.gz und das DCGM-Diagnoselog.
5. Angaben zur Anwendung, falls der Fehler an eine bestimmte Anwendung gebunden ist.

NVIDIA bezeichnet seine Felddiagnose als „das maßgebliche und umfassende NVIDIA-Werkzeug zur Bestimmung des Zustands von GPUs“ und schreibt, sie sei „in der Regel erforderlich, bevor eine RMA gestartet werden kann“; wann und wie sie auszuführen ist, sagt der Systemhersteller.

Bei GPUs, die Sie bei uns gekauft haben, läuft die Herstellergarantie über uns. Schicken Sie uns die XID-Zeilen, die Seriennummern und den Bug-Report über das Formular unten, und wir antworten innerhalb eines Werktages.

Was wir liefern

Wir liefern die Karten, die diese Referenz abdeckt: die H200 NVL mit NVLink-Brücken, die L40S und die L4, die RTX PRO 6000 Server Edition und die weiteren GPUs der Reihen RTX PRO Blackwell und RTX Ada, mit Herstellergarantie, Ersatz von DOA-Geräten und Support durch das Serviceteam unseres Engineering-Partners. Mit diesen Karten bauen wir KI-Server auf Bestellung, vor dem Versand unter Last getestet, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und Container-Runtime, unter einem EU-Vertrag und auf einer Rechnung.

FAQ