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.
Quellen
- CloudRift: Bug Bounty & detaillierte Repro (Logs, Setup)
- Tom’s Hardware: Reset-Bug trifft RTX 5090 & RTX Pro 6000, Kopfgeld ausgesetzt
- VideoCardz: Berichterstattung & Kontext zum Reset-Fehler
- Nvidia Developer Forum: Proxmox-Passthrough friert Host (Log-Beispiele)
Über den Autor
Letzte Aktualisierung am 5.02.2026 / 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.
