Was hinter dem Blackwell-Reset-Bug steckt – und was du jetzt tun kannst

Die ersten Monate mit Nvidias Blackwell-Generation verlaufen nicht so reibungslos, wie viele Virtualisierungs- und AI-Teams gehofft hatten: In produktiven KVM/VFIO-Setups berichten Betreiber darüber, dass GeForce RTX 5090 und RTX Pro 6000 nach einem Geräte-Reset in einen nicht mehr ansprechbaren Zustand geraten. Der Effekt ist dramatisch: Die GPU lässt sich weder neu binden noch resetten, betroffene Hosts müssen hart neu gestartet werden – mit allen Risiken für laufende Workloads. Ein GPU-Cloud-Anbieter hat inzwischen ein Kopfgeld von 1.000 US-Dollar auf eine belastbare Abhilfe ausgesetzt. Wir ordnen die Fakten, zeigen, was reproduzierbar ist, und skizzieren Workarounds, bis Nvidia eine offizielle Lösung liefert.

Das Fehlerbild in der Praxis

Der Auslöser ist in den meisten Fällen ein regulärer Function-Level-Reset (FLR) nach dem Shutdown einer VM oder bei der Neuzuweisung der GPU. Statt in einen definierten Grundzustand zurückzukehren, antwortet die Karte nicht mehr – typische Kernel-Logs zeigen „not ready … after FLR; giving up“, anschließend meldet lspci „unknown header type 7f“. Versuche, die Karte erneut an den Nvidia-Treiber zu binden, scheitern häufig daran, dass das Gerät in D3cold verharrt („Unable to change power state from D3cold to D0, device inaccessible“). Der Host kann in einen Soft-Lockup laufen; ein sauberer Recovery-Pfad fehlt – es hilft dann nur noch ein kompletter Reboot des Hosts.

Betroffene Hardware & Software-Stacks

Nach aktuellem Kenntnisstand häufen sich die Probleme speziell bei Blackwell-Karten in VFIO-Passthrough-Szenarien mit QEMU/KVM, etwa auf Proxmox-Hosts. Die Berichte reichen von Early-Adopter-Threads im Frühjahr 2025 bis zu Produktionsumgebungen bei GPU-Cloud-Betreibern. Ältere oder andere Nvidia-Generationen wie RTX 4090 (Ada) sowie H100/B200 (Hopper/Blackwell-Data-Center) gelten in den vorliegenden Tests als unauffällig.

Komponente	Status / Beobachtung	Quelle
GeForce RTX 5090 (Blackwell)	Reproduzierbarer Reset-Bug nach VM-Shutdown/Neu-Bindung (FLR), Host ggf. Soft-Lockup	Tom’s Hardware, Level1Techs
Nvidia RTX Pro 6000 (Blackwell)	Gleiches Fehlerbild wie 5090 bei VFIO/KVM-Passthrough	CloudRift, Proxmox-Forum
RTX 4090 (Ada)	Kein entsprechendes Fehlverhalten beobachtet	ITdaily, Tom’s Hardware
H100 / B200	Keine vergleichbaren Ausfälle gemeldet	ITdaily

Details aus einer Produktionsrepro zeigen ein modernes Stack-Profil (u. a. Linux 6.11, libvirt 10, QEMU 8.2), das die gängigen Best Practices (VFIO-Bindung beim Boot, kein Treiber-Rebinding durch libvirt) berücksichtigt – die üblichen Konfigurationsfehler (IOMMU/ACS/ASPM) sind in diesen Fällen also eher nicht die Ursache.

Timeline: Von den ersten Community-Reports zum Kopfgeld

Bereits Ende März 2025 meldeten frühe 5090-Besitzer in der Level1Techs-Community Soft-Lockups nach dem FLR im Proxmox-Passthrough. Im Sommer verdichteten sich Hinweise im Proxmox-Forum und auf Nvidias Developer-Forum, ehe Anfang August ein GPU-Cloud-Provider das Problem öffentlich machte und eine detaillierte Repro samt Logfiles veröffentlichte. In der Woche ab 7. September 2025 folgte breite Berichterstattung in Tech-Medien.

Warum gerade Blackwell? Hypothesen zur Ursache

Offizielle Root-Cause-Angaben gibt es bislang nicht. Aus den Logs und der Streuung der Berichte lassen sich jedoch Arbeitshypothesen ableiten: (1) Ein Firmware-/Hardware-Handling der FLR-Sequenz, das die Karte unter bestimmten Umständen in D3cold „einschläft“ und nicht korrekt wieder aufweckt. (2) Ein Timing-Problem zwischen Host-Treiber, IOMMU-Gruppierung und dem Re-Init des Geräts bei Multifunktions-Geräten (GPU + Audio-Funktion). (3) Ein Blackwell-spezifischer Zustand, der FLR-Kommandos ignoriert und die PCIe-Funktion in einen „limbo“ versetzt („unknown header type 7f“). Da Ada- und diverse Data-Center-Modelle unauffällig sind, spricht die Evidenz eher gegen einen generischen VFIO/KVM-Bug und für eine Blackwell-Spezifik.

Wirtschaftlicher Impact: Von Homelabs bis Multi-Tenant-Clouds

Für Homelabs ist ein Host-Reboot ärgerlich; in produktiven Multi-Tenant-Umgebungen ist er geschäftskritisch, weil laufende VMs auf dem Knoten mitgerissen werden. GPU-Cloud-Anbieter berichten, dass der Bug „zufällig“ nach Tagen auftreten kann – besonders heikel bei Langläufern (Training, Fine-Tuning). Entsprechend wurde ein Kopfgeld von 1.000 US-Dollar auf eine robuste Abhilfe oder eine belastbare Root Cause ausgelobt, um das Thema zu beschleunigen.

Offizieller Status von Nvidia

Stand 13. September 2025 liegt kein öffentlich dokumentiertes Fix-Advisory oder detailliertes Technik-Statement vor; Medienberichte heben den fehlenden offiziellen Kommentar hervor. In Foren finden sich einzelne Moderator-Antworten zu Blackwell-Themen, jedoch keine klar kommunizierte, verifizierte FLR-Fix-Roadmap für RTX 5090/RTX Pro 6000. Bis ein Treiber-/Firmware-Update verfügbar ist, bleibt die Lage für Virtualisierer angespannt.

Workarounds & Risikobewertung (vorläufig)

Es gibt keinen „Silver Bullet“. Dennoch kristallisieren sich Maßnahmen heraus, die in einigen Umgebungen die Häufigkeit reduzieren oder Recovery erleichtern. Achtung: Alle Workarounds sind mit Abstrichen verbunden – sorgfältig testen!

Ansatz	Idee	Risiken / Nachteile	Signal aus der Community
GPU am Host gebunden lassen, Passthrough minimieren	Auf klassischen vGPU/Remoting-Ansatz ausweichen statt vollem VFIO-Passthrough	Geringere Bare-Metal-Performance, Lizenz-/Feature-Einschränkungen	Allgemeiner Rat, bis FLR stabil ist
Treiber-Rebinding vermeiden	VFIO-Bindung früh (Boot) und `managed="no"` in libvirt, kein Runtime-Rebinding	Kein echter Fix – Bug tritt trotzdem sporadisch auf	Produktionsrepro zeigt bereits diese Praxis
IOMMU-/ACS-Topologie prüfen	Saubere Gerätegruppen, wo nötig testweise `pcie_acs_override`	Kann Sicherheit und Isolation beeinträchtigen	Hilft bei generischen Freeze-Fällen, nicht spezifisch Blackwell
ASPM/Power-States testen	ASPM abschalten, D3cold vermeiden	Höherer Idle-Verbrauch, keine Garantie	Einzelberichte; kein konsistenter Erfolg
Host-seitige Watchdogs/Canaries	Automatisches Erkennen des „limbo“ (PCIe-Header 7f) und orchestrierter Knoten-Failover	Engineering-Aufwand, kein Verhindern des Bugs	Cloud-Betreiber empfehlen Betriebskonzepte

Die klassische Sammlung an „GPU-Passthrough friert ein“-Tipps (IOMMU-Gruppen säubern, ACS einschalten, Board-BIOS aktualisieren, Kernel/Libvirt/QEMU auf Stand bringen) kann generische Probleme lösen, adressiert aber den hier beschriebenen FLR-Pfad nur bedingt. Einige Nutzer melden temporäre Besserung durch geänderte Bindereihenfolgen (ROM BAR, Modesetting), die Evidenz ist jedoch uneinheitlich.

Was die Karten an sich können – und warum das Thema wichtig ist

Die RTX Pro 6000 (Blackwell) ist als Workstation-Spitze mit 96 GB GDDR7 und Next-Gen Tensor/RT-Cores positioniert; die GeForce RTX 5090 bringt Blackwell-Leistung in den Consumer-Bereich (u. a. 32 GB GDDR7). Genau diese Zielgruppen – AI, 3D, DCC, HPC-Prototyping – setzen häufig auf flexible VM-Zuweisung. Ein instabiler FLR torpediert Multi-Tenant-Clouds, CI/CD-Pipelines mit automatischem GPU-Recycling und Dev-Environments, die GPUs zwischen Gästen rotieren lassen.

Konkrete Empfehlungen für Betreiber

1) Risiko evaluieren: Falls deine Knoten produktive Langläufer hosten (Training, Rendering), plane konservativ und minimiere VFIO-Reassignments. 2) Architektur anpassen: Wo möglich, GPUs persistent einer VM zuordnen (kein häufiger FLR), Workload-Scheduling drumherum bauen. 3) Monitoring/Auto-Failover: Erzeuge Health-Checks, die PCIe-Fehlerbilder („unknown header type 7f“, D3cold-Reste) früh erkennen und Workloads automatisiert migrieren oder Jobs neu planen. 4) Support-Pfad öffnen: Halte Log-Sätze (dmesg, libvirt-Logs, QEMU-Cmdline) parat, um bei Nvidia-Tickets/Partnern belastbare Artefakte zu liefern. 5) Test-Fenster vor Deployments: Treiber- und Firmware-Updates zunächst auf Canary-Knoten ausrollen.

Ausblick: Was als Nächstes zählt

Die breite Aufmerksamkeit – von Foren über Cloud-Betreiber bis zu großen Tech-Seiten – erhöht den Druck auf Nvidia, einen reproduzierbaren Fix zu liefern. Realistisch sind Firmware-/Treiber-Anpassungen rund um Power-State-Transitions und FLR-Sequenzen. Bis dahin gilt: Workarounds bewusst einsetzen, Betriebsmodelle anpassen – und Test-/Monitoring-Disziplin hochfahren.

FAQ: Die wichtigsten Fragen kurz beantwortet

Trifft es nur KVM/VFIO? Die überwiegende Evidenz stammt aus KVM/VFIO-Passthrough-Szenarien (Proxmox, Libvirt). Für andere Hypervisoren gibt es aktuell weniger belastbare Berichte.

Ist meine Karte „defekt“? Einzelne Forenthreads diskutieren DOA-Fälle, das Reset-Thema wirkt jedoch systematisch an Blackwell+VFIO gebunden – nicht als reiner Hardware-Ausfall.

Hat Nvidia das Problem bestätigt? Öffentliche, technische Details fehlen; Medien verweisen auf „kein Kommentar bisher“. Beobachte Treiber-/Firmware-Notes.

Welche Karten sind sicher? Erfahrungsberichte nennen RTX 4090/H100/B200 als unauffällig; belastbar ist nur, was du im eigenen Stack prüfst.

Ressourcen für die Fehlersuche

Für tieferes Debugging lohnen sich: vollständige libvirt-Logs mit QEMU-Cmdline, dmesg-Schnitte rund um den FLR, PCIe-Rescans, sowie klare Dokumentation der Bindereihenfolge (vfio-pci ↔︎ nvidia). Eine öffentlich verfügbare Repro samt Log-Artefakten findet sich bei einem GPU-Cloud-Betreiber; Community-Threads liefern ergänzende Varianten und Testansätze.

ASUS TUF Gaming GeForce RTX 5070 Ti 16GB GDDR7 OC…

Angebot

ASUS ROG Astral GeForce RTX 5090 32GB GDDR7 OC…

MSI GeForce RTX 5060 Ti 16G Shadow 2X OC Plus -…

Letzte Aktualisierung am 1.09.2025 / Affiliate Links / Bilder von der Amazon Product Advertising API. Alle hier angezeigten Preise und Verfügbarkeiten gelten zum angegebenen Zeitpunkt der Einbindung und können sich jederzeit ändern. Der Preis und die Verfügbarkeit, die zum Kaufzeitpunkt auf Amazon.de angezeigt werden, sind maßgeblich. Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.