Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.
Fehlerstufe finden, bevor ein Boot-Parameter geändert wird
Fehler 802 ist ein Symptom; Nachweise zu Host-Treiber und NVSwitch-Initialisierung bestimmen den nächsten Diagnoseschritt.
KI-gestützte Lernvisualisierung · schematische Erklärung zum Artikel
Schritt 1 / 4Sichtbarkeit und Bereitschaft trennen
Eine GPU kann in nvidia-smi erscheinen, während die CUDA-Initialisierung fehlschlägt. Halte die fehlschlagende Operation und genaue Versionen für spätere Vergleiche fest.
Der Kernelparameter nokaslr deaktiviert die zufällige Platzierung von Kernel und Modulen, wie die Linux-Kernel-Dokumentation beschreibt. Er wird als Behelf für einige NVIDIA-CUDA-Initialisierungsfehler genannt. Er ist keine allgemeine Lösung für schwarze Bildschirme, gescheiterte Treiberinstallationen oder CUDA-Fehler 802 unter Ubuntu 24.04. Die frühere Fassung dieser Anleitung behandelte die KASLR/CUDA-HMM-Erklärung eines Forennutzers als bestätigte Ursache. Das gibt die zitierte Diskussion nicht her.
In einem NVIDIA-Entwicklerforum berichtete ein Nutzer mit B200-System, dass nvidia-smi die GPUs anzeigte, CUDA aber Fehler 802 meldete. Später führte er dies auf KASLR/CUDA HMM zurück und schlug nokaslr vor. Das ist ein Nutzerbericht, keine NVIDIA-Entwicklungsmitteilung oder kontrollierte Ursachenanalyse.
Ein anderer Teilnehmer mit Fehler 802 schrieb ausdrücklich, dass das Deaktivieren von KASLR nicht half. In seinem Fall konnte Fabric Manager ib_umad nicht laden; eine Korrektur der InfiniBand-Installation löste das Problem. Der gleiche Fehlercode beweist somit keine KASLR-Ursache. Bei NVSwitch-Systemen ist die Fabric-Manager-Dokumentation von NVIDIA der bessere Ausgangspunkt.
Wenn nvidia-smi fehlschlägt, zuerst den Host-Treiber anhand der Ubuntu-Treiberanleitung prüfen. Ein schwarzer Bildschirm oder ein fehlendes Kernelmodul kann viele Ursachen haben und belegt keinen KASLR-Konflikt.
Wenn nvidia-smi funktioniert, CUDA aber auf einem NVSwitch-System fehlschlägt, den Fabric-Manager-Dienst und seine Protokolle prüfen:
bash
systemctl status nvidia-fabricmanagerjournalctl -u nvidia-fabricmanager -b
Prüfen, ob Treiber- und Fabric-Manager-Version zusammenpassen, und Fehlermeldungen zu Modulen oder NVSwitch im Protokoll untersuchen. Auch NVIDIAs GPUDirect-Storage-Fehlerdiagnose verweist bei CUDA-System-not-ready auf NVSwitch-Systemen auf passende Versionen von Fabric Manager und Treiber.
Erst wenn andere Ursachen ausgeschlossen sind, kommt nokaslr als vorübergehender Diagnosetest bei vermuteter Kernelinteraktion infrage. Falls sich das Verhalten dadurch ändert, Kernel-, Treiber- und Hardwareversion festhalten und den Befund an den Hersteller melden. Eine Verhaltensänderung beweist für sich genommen den vorgeschlagenen CUDA-HMM-Mechanismus nicht.
Ein dauerhaftes nokaslr in der Bootkonfiguration schaltet eine Schutzmaßnahme gegen Kernel-Exploits ab. Fehler 802 allein rechtfertigt dies nicht. Nach Treiber- oder Kernelupdates ohne den Parameter erneut testen und eine bestätigte Herstellerkorrektur bevorzugen, sobald sie verfügbar ist.
