Arjab
Lt. Junior Grade
- Registriert
- Feb. 2013
- Beiträge
- 474
Moin,
falls das nicht das richtige Subforum für einen Erfahrungsbericht ist, kann der Thread auch gerne verschoben werden. Thematisch passen das "Linux" oder "Virtualisierung"-Unterforum ebenso. Da es aber vor allem um die verwendete Hardware geht, dachte ich, dass ich hier am richtigsten bin.
1. Meine alte Grafikkarte (MSI GTX 970 4G) soll als GPU für das Linux-Hostsystem verwendet werden. Da die neue Grafikkarte (MSI RX 5700 Evoke) für das Windows 10-Gastsystem verwendet werden soll, muss diese - für die beste Performance - in den ersten PCIe-Slot. Bei meinem neuen Mainboard (MSI B450 Tomahawk Max) kann man im BIOS jedoch nicht einstellen, von welcher GPU gebootet werden soll. Dafür gibt es zwar Fixes und Workarounds, aber ob's wirklich klappt, weiß ich nicht.
2. Die aktuellen GPUs von AMD haben scheinbar einen Reset-Bug und die Initialisierung der Grafikkarte des Gastsystems nach einem Neustart dessen stürzt ab - oder so. Es gibt auf jeden Fall auch dafür einen Kernel-Patch und ich bin gespannt, ob der funktioniert oder das Problem überhaupt auftritt.
Gerade warte ich noch auf eine Teilbestellung mit Netzteil und CPU-Kühler, hab' aber aus Ungeduld und Langeweile schon mal Prozessor, Arbeitsspeicher und Mainboard zusammengeworfen und tippe diesen Beitrag auf einem frisch installierten Manjaro Linux. Mit nur einer GPU im System bootet alles ganz problemlos, obwohl die GPU im vierten PCIe-Slot steckt. Mal sehen, ob sich das ändert, sobald ich die RX 5700 dazustecke.
Ich werd' hier in unregelmäßigen Abständen berichten, wie sich der weitere Prozess gestaltet. Fragt mich gerne nach spezifischen Dingen und ich hoffe, auf alles eine Antwort zu wissen. Ansonsten hoffe ich, dass hier einige interessierte Leute mitlesen und meine Bestellung bald ankommt.
Aber genug davon, der PC bootet problemlos und wie erwartet darf ich mein Festplatten-Passwort auf dem Bildschirm der RX 5700 eingeben, ebenso wie Manjaro Linux im GRUB auswählen, damit Linux dann nach der Initialisierung des „Simple Desktop Display Manager“ auf die GTX 970 wechselt und mir dort meinen Desktop anzeigt. So weit, so gut!
Ansonsten hab‘ ich IOMMU bzw. Virtualisierung in den sehr versteckten CPU-Einstellungen meines Mainboards aktiviert, den entsprechenden Kernel-Parameter gesetzt, damit IOMMU auch Software-seitig aktiviert ist, die IDs von GPU und dazugehörigem Audio-Controller ebenfalls als Kernel-Parameter gesetzt und die entsprechenden Module zum Initramfs hinzugefügt. Ich erspare euch mal die Details, wen es interessiert kann die einzelnen Schritte in der Arch Wiki nachlesen.
Tja und nach einem Reboot – ist alles beim Alten, das System bootet mit der RX 5700 und wechselt dann auf die GTX 970. Aber immerhin zeigen mir
Ich hab‘ dann mal diese Anleitung zu Rate gezogen, die mir @0-8-15 User in dem Kaufberatungs-Thread verlinkt hat, aber irgendwie hat auch das noch keine Früchte getragen. Ich werd‘ erstmal die VM einrichten, so wild ist es jetzt nicht, beim Booten kurz das Input des Monitors zu wechseln.
Noch 'ne Notiz am Rande, ich hab‘ mal Folding@Home angeschmissen und bei ~ 85 % CPU-Auslastung ist die CPU bei maximal 80° C.
Also, virt-manager gestartet, ein bisschen rumgebastelt, um meine zweite SSD direkt als Speichergerät zu Verfügung zu stellen (siehe unten), richtige OVMF-Firmware ausgewählt, CPU-"Netzstrutur" und "host-passthrough" manuell eingetragen, 12 von 16 GB Arbeitsspeicher hinzugefügt, als erste Boot-Option ein Windows 10 ISO, als zweite die VirtIO-Treiber und schließlich die SSD ergänzt, Netzwerk erstmal idiotensicher auch als komplettes Passthrough, weil ich vergessen habe NAT einzurichten, Maus und Tastatur ebenfalls (zur Not kann hab' ich noch 'ne zweite Maus) und natürlich die RX 5700 als PCIe-Gerät hinzugefügt.
Um eine SSD als Gerät hinzufügen zu können - weil Libvirt/virt-manager das nicht nativ unterstützt - muss man erst einen regulären Speicherpool (pool.qcow2) auf der formatierten und gemounteten SSD erstellen, den dann während der Einrichtung der VM und vor der Installation des OS wieder löschen und die SSD als Speichergerät mit
So, VM gestartet und, alles hängt, kein Bild von der RX 5700 und nur die zweite Maus und ein "Ausschalten erzwingen" konnte helfen. Ich mach' jetzt erstmal 'n Päuschen und berichte später nochmal..
EDIT #1:
Okay, ich hab' nochmal mit dem Boot-Medium rumexperimentiert (es musste wohl eine SATA CD-ROM sein) und jetzt ging's, also wenigstens über die Spice-Videoausgabe im Fenster vom virt-manager. Ich hab' zwar vergessen, welcher der richtige VirtIO-Treiber war, aber hab' dann diese hilfreiche Anleitung gefunden.
Nach der Installation von Windows 10 also noch schnell den VirtIO "Guest Agent" installiert und in dem Zuge auch gleich Firefox und die Radeon-Software. Die RX 5700 wird auf jeden Fall schon im Geräte-Manager angezeigt. Erstmal das System herunterfahren, Windows-ISO und VirtIO Treiber-Image aus der Bootreihenfolge nehmen und die SSD von SATA zu SCSI ändern. Tja und ein Neustarten der VM funktioniert dann nicht, wegen
EDIT #2:
Fuck, ich hätte die SSD
EDIT #3:
Hat zwar keiner nach gefragt, aber hier ist jetzt doch mal 'n Bild von der Maschine.
Aber zurück zu den wichtigen Dingen, der Grafikkarte! Also VM hochgefahren, die aktuellste Radeon Software installiert, Windows Updates gemacht, Host neugestartet, Gast auch neu gestartet (weil ich mich noch nicht um den Reset-Bug gekümmert habe) aber die RX 5700 wird nicht erkannt und die Radeon Software sagt mir, die Treiber seien nicht installiert.. Großartige Hilfe!
Nach kurzem Bemühen einer Suchmaschine kam ich dann drauf, mal im Geräte-Manager zu schauen, was die Grafikkarte eigentlich für 'n Gerätestatus hat und sehe den Fehlercode 43. Nach wiederum kurzer Recherche scheint das Problem mit den Kernel-Parametern zu tun zu haben, die den EFI-Framebuffer deaktivieren. Also die VM nochmal herunterfahren, diesmal mit Absturz des Linux-Hosts inklusive, neu gestartet und Kernel-Parameter geändert. Laut dem erstbesten Reddit-Post soll man
Was bleibt? To-Dos!
Außerdem hab' ich nochmal zum Reset-Bug recherchiert und mit dem Manjaro Kernel 5.3 bzw. 5.4 LTS ist der erste von zwei Patches enthalten. Hier der Thread zum Navi Reset Kernel Patch, hier der Beitrag zum Manjaro-Kernel und hier der Beitrag zum zweiten Patch.
Ich hab' einfach mal von Kernel 5.6.7-1 auf 5.4.35-1 gedowngradet und konnte meine VM tatsächlich herunterfahren, ohne dass der Host abgestürzt ist. Ein Neustart der VM hat allerdings nicht funktioniert, die GPU scheint also immer noch nicht richtig zu resetten. Auch ein zweites Mal kann ich die VM herunterfahren und mein Linux-System stürzt nicht ab. Aber ein Blick auf
Ich komme wohl nicht drumherum, den Kernel nochmal manuell zu patchen..
Außerdem habe ich mal meine Spiele-Partition ebenfalls
Erstmal bin ich wirklich froh, wie schnell die Einrichtung der virtuellen Maschine lief. Mal abgesehen von Recherche am Rande und ein paar "Flüchtigkeitsfehlern" war das schon fast routiniert im Vergleich zu meinem ersten Versuch, bei dem ich mir erst noch wirklich alles aneignen musste. Jetzt werd' ich mir wohl mal aneignen müssen, wie man 'n Manjaro-Kernel patched und kompiliert und denke, der Thread ist 'n guter Anfang.
EDIT #1:
Ich hab' jetzt mal 'n paar Benchmarks angeschmissen, weil es mich doch sehr interessiert, wie die VM überhaupt performt. ComputerBase hat ja eigene Test bzw. Benchmarks, sowohl vom Ryzen 5 3600, als auch von der RX 5700, die ich hier als Vergleich heranziehe.
Nochmal kurz die Infos zur VM:
Windows 10 Pro v1909 Build 18363.815
AMD Ryzen 5 3600 @3,60 GHz
12 GB G.Skill Aegis DDR4-3200, CL16
MSI Radeon RX 5700 Evoke GP OC, 8GB
Radeon Software v20.2.2
Beginnen wir mit der Grafikkarte!
Ich hab' mir Shadow of the Tomb Raider über Steam heruntergeladen, weil es in den Benchmarks von ComputerBase auftaucht, eine Trial Version zur Verfügung steht und einen eingebauten Benchmark hat. Ich hab' mich dabei an die Grafikeinstellungen des CB-Benchmarks gehalten, war aber zu faul, mir das Savegame herunterzuladen und hab' einfach den eingebauten Benchmark gemacht. Falls es jemand wirklich wissen will, lasse ich mich aber auch noch dazu überreden, exakt den CB-Benchmark zu machen, falls das mit der Trial Version überhaupt möglich ist.
Hier die Ergebnisse:
Die durchschnittlichen 65 FPS sind deutlich höher, als die 55,3 von ComputerBase, aber das kann an verschiedenen Dingen liegen, vor allem wahrscheinlich am integrierten Benchmark, das einfach nicht die tatsächliche Performance abbildet. Notiz am Rande, ich hab' auf die Schnelle diesen Artikel gefunden, der witziger Weise anhand von Tomb Raider erläutert, warum Benchmark-Tools problematisch sind. Irgendwie 'n unbefriedigendes Ergebnis, aber ich müsste nochmal nach Benchmarks von aktuellen Spielen suchen, die ich auch besitze.
So, erstmal weiter zum Prozessor:
Ich hab' einfach Cinebench R15 und R20 jeweils einmal im Multi Core-Test und einmal im Single Core-Test laufen lassen. Keine Ahnung warum, aber Cinebench R15 erkennt meinen Prozessor als 12 Kerner und mein Betriebssystem als Windows 8, aber das wird dem Benchmark ja keinen Abbruch tun.
Das sind die Ergebnisse, in den Klammern stehen die Ergebnisse von ComputerBase und die Differenz in Prozent:
Cinebench R15
CPU (Multi Core): 1499 cb (1581 cb; -5,19 %)
CPU (Single Core): 190 cb (197 cb; -3,55 %)
Cinebench R20
CPU (Multi Core): 3382 pts (3539 pts; -4,44 %)
CPU (Single Core): 465 pts (474 pts; -1,90 %)
Bis auf den realitätsfernen Grafikarten-Benchmark kann man wahrscheinlich sagen, dass die Performance relativ ähnlich ist. Laut dem Cinebench-Benchmarks ist der Prozessor im Durchschnitt keine 5% langsamer, als bei dem Benchmark von ComputerBase. Das ist aber auch nicht sonderlich verwunderlich, weil ja alle CPU-Kerne bzw. Thread und die komplette GPU durchgereicht werden.
Ich werde mich jetzt erstmal wieder dem Kernel-Patch widmen..
Die bereits verlinkte Anleitung hat gleich in zwei Punkten nicht für mich zugetroffen. (Die Seite ist übrigens von einem Tag auf den anderen mal off- und mal online, darum oben der Direktlink und hier ein Link zum Web Archive.)
Also 1. ist der Kernel-Parameter in der Anleitung falsch bzw. ich glaube veraltet und damit redundant beschrieben (und man muss ihn richtig abtippen!) und 2. musste ich das Compatibility Support Module (CSM) ausschalten und nicht einschalten. Das CSM ermöglicht älterer Hardware das Booten mit Legacy BIOS statt UEFI. Naja, jedenfalls hab' ich es mehr aus Spaß einfach mal ausgeschaltet und siehe da, mein Computer bootet von der GTX 970! Jetzt bleibt mir endlich das nervige Display-Input wechseln nach dem Eingeben meines Festplatten-Passworts erspart und mir wird obendrein noch das schicke Mainboard-Logo und die Boot-Hotkeys angezeigt - wunderbar.
Jetzt aber versprochen als nächstes der Kernel-Patch..
Man sollte die angelegten Speicherpools, die für das Durchreichen von Festplatten bzw. Partitionen nötig sind natürlich wieder löschen. Bei mir waren das einmal eine 20 GB Datei mit der
Außerdem sollte man die im virt-manager hinterlegten Pfade dieser Speicherpools löschen. Das ist nicht besonders wichtig, aber verhindert zum einen eine Fehlermeldung im journalctl vom libvirtd-Service und verhindert außerdem Verwirrung beim hinzufügen von weiteren Speicherpool bzw. -geräten. Dazu muss man den virt-manager und die Konfiguration irgendeiner virtuellen Maschine öffnen, dort auf "Gerät hinzufügen" -> "Speicher" -> "Benutzerdefinierten Speicher auswählen oder erstellen" -> "Verwalten..." und dann öffnet sich die Übersicht über die "Speicherdatenträger". Hier habe ich zwei Pfade, die auf die ehemals in meinem /run/media-Verzeichnis gemounteten Festplatten verweisen und einfach gelöscht werden können.
Außerdem hab' ich (wie viele) den Ryzen-Hypetrain mitgefahren und hab' mich (ebenfalls wie viele) über die hohen Temperaturen gewundert. Mit dem Standardtakt von 3,6 GHz komme ich unter Last von ~ 85 % CPU-Auslastung durch Folding@Home auf 85° C. Nebenbei steht mein alter Intel Core i5-3570 mit Standardtakt unter 100 % Volllast durch Folding@Home bei gemütlichen 50° C in der Zimmerecke - allerdings auch ohne Gehäuse. Mit aktiviertem MSI Game Boost im BIOS und dem damit erhöhten Takt auf bis zu 4,2 GHz komme ich bei gleicher Last auf über 100° C und habe an dieser Stelle den Test abgebrochen, weil die CPU ohnehin ab 95° C drosselt. Aber warum schreibe ich das?
Einerseits möchte ich natürlich alle für Folding@Home begeistern!
Andererseits möchte ich aber vor allem auf dieses Statement eines AMD-Mitarbeiters auf Reddit aufmerksam machen, was nicht nur detailliert erklärt, wie und warum die Temperaturen zustande kommen, sondern auch, wie und mit welchen Einstellungen man seinen Ryzen-Prozessor am besten nutzt.
Ansonsten läuft meine GTX 970 auch ganz wunderbar unter Manjaro Linux und weniger anspruchsvolle Spiele wie Minecraft (mit Shadern) oder CS:GO laufen hervorragend. Und ich habe letzens noch diese Anleitung entdeckt, die erklärt, wie man mit PRIME eine Grafikkarte sowohl unter dem Host- als auch unter dem Gast-System verwenden kann. Wenn ich denn irgendwann mal den Reset Bug bearbeitet habe, juckt es mich außerdem noch in den Fingern, das auszuprobieren..
Ich hab' mich vor allem an diese kurze Anleitung gehalten und die dort verlinkten Wiki-Artikel.
Zunächst sollte man nachschauen, welchen Kernel man aktuell nutzt und welche installiert sind. Das kann man mit dem Befehl
Als nächstes sollte man sich vergewissern, dass man
Jetzt klonen wir das Git-Repository des bevorzugten Kernels in einen neuen Ordner. Also einen neuen Ordner im
In das Verzeichnis wechseln:
Und das Repository klonen:
Dabei ist wichtig,
Jetzt sollte in dem
An dieser Stelle sollte man in das
Dann hier den Text des Patches kopieren und eine neue Datei erstellen:
Den Patch einfügen, eine Zeile wie in diesem Post beschrieben ändern:
Die Datei speichern und den Editor verlassen.
Jetzt müssen wir dem
In der Datei findet man unter der Zeile, die mit
Außerdem muss unter der Zeile, die mit
Dann die Datei einfach speichern und den Editor beenden.
Da sich jetzt die Prüfsumme der
Nun kann man den Kernel kompilieren. Das kann bis zu einige Stunden dauern, bei ging's mit lediglich 'ner Viertelstunde relativ schnell:
Danach kann man den kompilierten Kernel mit
Jetzt das System neu starten und wieder mit
Ich hab' euch bis zu dieser Stelle übrigens erspart, jeden noch so kleinen Fehler und meine zahllosen Versuche des Kompilierens zu dokumentieren. So hat dieses Update noch mehr den Charakter einer kurzen Anleitung und wahrscheinlich wird es niemanden interessieren, wie oft ich vergeblich versucht habe
Aber vor allem sollte jetzt hoffentlich der Reset Bug gepatcht sein!
Also die virtuelle Maschine gestartet, um sie dann sofort wieder herunterzufahren. Leider spuckt
Ein erneutes Starten der VM funktioniert zwar ohne Fehlermeldung vom virt-manager, aber leider ist
Ich werd' das Prozedere nochmal mit anderen Kernel-Versionen wiederholen und ein bisschen weiter recherchieren. Wenigstens weiß ich jetzt, wie man 'n Kernel patcht und kompiliert und dass der Reset Bug nicht so leicht zu beheben ist, wie gedacht..
Tatsächlich ist es nämlich häufig relativ problematisch, das Audiosignal der VM verzögerungsfrei und in voller Qualität aus dem Ausgabegerät der Wahl zu kriegen. Außerdem besitzt man - wie auch bei Tastatur, Maus und sonstigen Peripheriegeräten - wahrscheinlich nur ein Paar Lautsprecher oder Kopfhörer, über das man je nachdem das Audiosignal von Host- oder Gastsystem hören möchte.
In meinem Fall wird die Sache noch ein bisschen schwieriger, weil ich ein USB-Audiointerface benutze, an dem sowohl meine Lautsprecher, als auch meine Kopfhörer angeschlossen sind. Natürlich könnte man einfach den USB-Anschluss an die VM weiterreichen, was aber oft viel zu hohe Latenz oder furchtbare Verzerrungen mit sich bringt. Man könnte stattdessen auch das PCI-Gerät, an das der entsprechende USB-Controller angeschlossen ist an die VM weiterreichen. Damit werden aber auch alle anderen USB-Anschlüsse an die VM weitergereicht, die mit diesem PCI-Gerät verbunden sind und meine letzte virtuelle Maschine hat sich mit dieser Lösung oft schwer getan.
Deutlich einfach ist es, das Audiosignal der virtuellen Maschine mit PulseAudio an das Host-System quasi zurückzureichen. Der Abschnitt dazu in der Arch Wiki hat mir ehrlich gesagt nicht auf Anhieb eingeleuchtet, dafür aber dieser Artikel von Passthrough Post. Seit Qemu 4.0 reicht es nämlich aus, einige wenige Zeilen in der Konfigurationsdatei der VM zu ändern. Dazu muss man die XML-Datei (am einfachsten mit nano) editieren:
Hier müssen dann folgende Zeilen geändert werden:
Dazu installiert man sich am besten pavucontrol, um den Audiostream einstellen zu können. Und ein kurzer Test zeigt, dass der Audiostream meiner VM win10 mit der gesetzten PulseAudio-ID pa1 korrekt an mein USB-Audiointerface Steinberg UR22 weitergegeben wird:
Ich hab' während der Konfiguration übrigens die Grafikkarte aus der VM entfernt, um diese zum Testen einfach hoch- und wieder runterfahren zu können, daher die Videoausgabe über das Fenster vom virt-manager.
Andere Peripheriegeräte, wie z.B. Maus und Tastatur oder ein USB-Controller kann man übrigens problemlos als USB-Gerät an die VM durchreichen. Bei Eingabegeräten muss man sich nur darüber im Klaren sein, dass diese dann an die VM weitergereicht werden und nicht mehr für das Host-System funktionieren. Das ist vor allem wichtig, falls die VM abstürzt oder anderweitig nicht funktioniert, aber trotzdem die Eingabegeräte für sich beansprucht. Hierfür kann man entweder auf eine zweite Maus oder Tastatur, über SSH, VNC oder Software wie Teamviewer auf das Host-System zugreifen.
1. Nach einem Update auf QEMU Version 5 hat mein Windows 10 mir nach dem Hochfahren einen Bluescreen mit der Fehlermeldung KERNEL SECURITY CHECK FAILURE angezeigt. Ich dachte, dass bei einem der zahllosen Abstürze meines System aufgrund des Navi Reset Bugs beim Rumexperimentieren in den letzten Tagen irgendwelche Systemdateien beschädigt wurden. Daraufhin hab' ich wie verrückt versucht, das Windows-System mit einem Installationsmedium zu reparieren, aber nichts hat funktioniert. Nach weiterer Recherche bin ich dann irgendwann drauf gekommen, dass es schlicht an QEMU liegt und man - wie in diesem Post beschrieben - nur in der CPU-Konfiguration der virtuellen Maschine das Modell von host-passthrough auf host-model ändern muss.
Hier gibt es wohl auch noch anderes Workaround über die XML-Konfigurationsdatei der virtuellen Maschine, aber das schaue ich mir bei Gelegenheit an.
2. Ähnlich abgemüht hab' ich mich mit dem fehlenden Treiber für den SCSI-Controller und hab' wirklich versucht jeden einzelnen Treiber zu installieren, aber immer ohne Erfolg. Ich weiß schon gar nicht mehr, wie ich hier drauf gekommen bin, aber es lag ebenfalls nicht an Windows, sondern der falschen Konfiguration im virt-manager. Hier hat jedes (Speicher-)Gerät einen zugehörigen Controller, entsprechend gibt es auch einen Controller Virtio SCSI 0, an dem meine beiden Festplatten angeschlossen sind. Hier war das Modell des Controllers auf Hypervisor-Standard gestellt, benötigt jedoch VirtIO SCSI um zu funktionieren. Also hab' ich das kurz geändert, es hat auf Anhieb funktioniert und der SCSI-Controller ist nicht mehr als "treiberlos" im Geräte-Manager aufgetaucht.
3. Nach diesen zwei wirklich ärgerlichen Flüchtigkeitsfehlern hat außerdem irgendwann der Audio-Stream mit PulseAudio nicht mehr funktioniert und ich hab' bis jetzt nicht verstanden, was das Problem war. Ich hab' schlicht einen entscheidenden Teil der Anleitung aus der Arch Wiki vergessen umzusetzen oder hier zu dokumentieren und irgendwie hat es bei der ersten Einrichtung trotzdem funktioniert. Darum hier der Nachtrag:
Man muss auch die /etc/libvirt/qemu.conf-Datei ändern und den eigenen Benutzernamen eintragen, damit PulseAudio weiß, an wessen Sitzung das Audiosignal gestreamt werden soll:
Dann die Zeile
So langsam werd' ich leider auch zunehmend pessimistischer was den Navi Reset Bug angeht. Ich werd' gleich nochmal den Kernel 5.7 patchen und installieren, aber denke nicht, dass das funktionieren wird. Entweder ich kaufe mir auch doch noch eine RTX 2060, aber die hat weniger Leistung als die RX 5700 oder ich verwerfe das PCI-Passthrough, was wirklich schade wäre! Ich bin unschlüssig..
Bei der installation werden gleich alle installierten Kernel aktualisiert und nach einem Neustart bin ich auch wieder auf meinem gewohnten Desktop gelandet. Anstatt die Grafikkartentreiber manuell zu installieren, kann man das übrigens auch einfach mit nvidia-dkms automatisieren.
Wieder ist aber die viel spannendere Frage, ob der gepatchte Kernel den Navi Reset Bug beheben konnte, aber leider ist das auch dieses Mal nicht der Fall. Nach dem Herunterfahren der virtuellen Maschine ist mein Linux-Host komplett eingefroren, abgestürzt und nach kürzester Zeit wurde der Bildschirm einfach schwarz. Auch ein zweiter Versuch kam beim gleichen Ergebnis raus..
Spannend finde ich dabei aber, dass nicht die üblichen Kernel-Fehlermeldungen auftauchen - also gar keine. Vielleicht werde ich da nochmal im Thread vom Level1Tech-Forum nachfragen, ob und wie man den Absturz debuggen kann.
Trotzdem bin ich heute optimistischer was die ganze PCI-Passthrough Geschichte und den elendigen Reset Bug angeht. Doch noch eine Nvidia Grafikkarte zu kaufen erscheint mir ziemlich sinnlos und wäre auch einfach deutlich teurer, als das ganze Projekt ohnehin schon ist. Und auch ein Dual-Boot System erscheint mir wie ein fauler Kompromis. Tatsächlich gefällt mir die Situation gerade nämlich doch besser, als ursprünglich angenommen und entspricht fast meinen Vorstellungen. Mein System bootet immer und ausschließlich ein Linux-System und kein Windows kommt mir mehr als bare-metal Installation ins Haus. Aus meinem Linux-System heraus kann ich dann die virtuelle Maschine starten, zocken und dann leider in einem Rutsch und gezwungener Maßen beide Systeme herunterfahren - aber sei es drum. Tatsächlich dient das Windows Gast-System ja auch "nur" dazu, die Spiele spielen zu können, die unter Linux gar nicht laufen, wie z.B. GTA Online. Wenn ich dann in absehbarer Zukunft doch noch hinbekomme, die RX 5700 unter beiden Systemen zu verwenden, wäre die gesamte Situation noch besser, aber wahrscheinlich macht mir hier auch der Reset Bug einen Strich durch die Rechnung.
Abgesehen davon würde ich an dieser Stelle auch nochmal ein positives Zwischenfazit ziehen, wenn ich mir meine bisherige Wall of Text so anschaue! Nicht nur hat es Spaß gemacht, mal wieder einen Computer zusammenzubauen, ich hab' auch die üblichen Fehler des PCI-Passthroughs bewältigt, sei es von der richtigen Grafikkarte im "falschen" PCI-Slot zu booten oder der klassische Fehlercode 43. Außerdem hab' ich meinen ersten Kernel kompiliert und die virtuelle Maschine mit SCSI-Treibern und PulseAudio nach meine Wünschen konfiguriert. Und obwohl die Rückmeldung hier eher verhalten ist, bin ich doch auch froh drüber, diesen Erfahrungsbericht geschrieben zu haben. Was man während einer Pandemie halt so macht..
Und auf Wunsch von @lokon hier meine BIOS-Version und IOMMU-Gruppen:
BIOS via dmidecode:
IOMMU-Gruppen via Skript:
Zum einen hab' ich mein komplettes System neu installiert, meine GTX 970 rausgeschmissen und PCI-Passthrough den Rücken gekehrt. Warum? Vor allem, weil GTA Online einfach hervorragend mit Lutris läuft. Zum anderen, weil ich ein rastloser Nerd bin und mich auch mal mit Wine, Proton und Lutris auseinandersetzen wollte. Nebenbei läuft Counter Strike: Global Offensive auch nativ super auf Linux.
Falls jemanden meine ambivalente Erfahrung mit Gaming on Linux interessiert, kann ich dazu gerne noch mehr Erfahrungen teilen.
Zum anderen hat Gnif, der Entwickler des Navi Reset Kernel Patches mit zwei Kollegen ein Kernel Modul entwickelt, mit dem man einerseits Grafikkarten zurücksetzen kann ohne den Kernel patchen zu müssen. Andererseits sind die neuen Grafikkarten von Nvidias RTX 3000 Serie und vom AMDs Radeon 6000 Serie weder vom Error Code 43 noch vom Reset Bug betroffen. Das behauptet jedenfalls Linus und im Fall von AMD bestätigt das Wendell von Level1Tech. Zu Nvidia konnte ich selber gerade nichts finden und auch Reddit hat noch keine Bestätigung dazu gefunden.
Also, vergesst nahezu alles, was ich geschrieben habe - juhuu! PCI-Passthrough ist gerade wahrscheinlich einfacher denn je, sofern man eine der neuen Grafikkarten besitzt. Und da es sich bei den Fehlern um Software-seitige Probleme handelt, ist davon auszugehen, dass auch ältere Grafikkarten mit einem Treiber oder Firmware-Update nicht mehr von den Fehlern betroffen sein werden. Sofern Nvidia und AMD gütig sind..
Oder man spart sich gleich die Mühe, wenn man die gewünschten Spiele in der LutrisDB oder ProtonDB findet und spielt einfach auf Linux!
Wenn ihr Rückmeldung und Fragen habt, schreibt mir gerne in die Kommentare. Ich bin immer gespannt auf den Austausch über andere Erfahrungen. Und jetzt versuche ich erstmal Red Dead Redemption 2 zum laufen zu bringen..
falls das nicht das richtige Subforum für einen Erfahrungsbericht ist, kann der Thread auch gerne verschoben werden. Thematisch passen das "Linux" oder "Virtualisierung"-Unterforum ebenso. Da es aber vor allem um die verwendete Hardware geht, dachte ich, dass ich hier am richtigsten bin.
Hier ein kleines Inhaltsverzeichnis:
- Einleitung
- Update #1 - Einrichtung und SSD-Passthrough
- Update #2 - Neuinstallation und Fehlercode 43
- Update #3 - AMD Reset Bug und Benchmarks
- Update #4 - Boot-GPU einrichten
- Update #5 - Virt-Manager Speicherpools und Ryzen-Temperatur
- Update #6 - Linux-Kernel patchen und kompilieren
- Update #7 - Audio-Passthrough mit PulseAudio
- Update #8 - Bluescreen und Korrektur
- Update #9 - Kernel patchen und Grafikkartentreiber
- Update #10 - Danke für die Blumen
- Update #11 - Alles ist anders!
Einleitung:
Nachdem mein aktuelles System bereits mit Manjaro Linux lief und ich mit KVM/Qemu und libvirt meine Grafikkarte via PCI-Passthrough an eine virtuelle Maschine mit Windows 10 durchgereicht habe, hab' ich besagtes System einer Aufrüstung unterzogen, wie ihr hier nachvollziehen könnt. Jetzt ist der große Spaß, alles wieder neu einrichten zu dürfen. Also Manjaro Linux auf neuer Hardware installieren, aber vor allem PCI-Passthrough und eine virtuelle Maschine (VM) einrichten. Dabei gibt es ohnehin mehrere Fallstricke, aber vor allem kann es konkret zu folgenden Problemen kommen:1. Meine alte Grafikkarte (MSI GTX 970 4G) soll als GPU für das Linux-Hostsystem verwendet werden. Da die neue Grafikkarte (MSI RX 5700 Evoke) für das Windows 10-Gastsystem verwendet werden soll, muss diese - für die beste Performance - in den ersten PCIe-Slot. Bei meinem neuen Mainboard (MSI B450 Tomahawk Max) kann man im BIOS jedoch nicht einstellen, von welcher GPU gebootet werden soll. Dafür gibt es zwar Fixes und Workarounds, aber ob's wirklich klappt, weiß ich nicht.
2. Die aktuellen GPUs von AMD haben scheinbar einen Reset-Bug und die Initialisierung der Grafikkarte des Gastsystems nach einem Neustart dessen stürzt ab - oder so. Es gibt auf jeden Fall auch dafür einen Kernel-Patch und ich bin gespannt, ob der funktioniert oder das Problem überhaupt auftritt.
Gerade warte ich noch auf eine Teilbestellung mit Netzteil und CPU-Kühler, hab' aber aus Ungeduld und Langeweile schon mal Prozessor, Arbeitsspeicher und Mainboard zusammengeworfen und tippe diesen Beitrag auf einem frisch installierten Manjaro Linux. Mit nur einer GPU im System bootet alles ganz problemlos, obwohl die GPU im vierten PCIe-Slot steckt. Mal sehen, ob sich das ändert, sobald ich die RX 5700 dazustecke.
Ich werd' hier in unregelmäßigen Abständen berichten, wie sich der weitere Prozess gestaltet. Fragt mich gerne nach spezifischen Dingen und ich hoffe, auf alles eine Antwort zu wissen. Ansonsten hoffe ich, dass hier einige interessierte Leute mitlesen und meine Bestellung bald ankommt.
Update #1 (23. April 2020):
So, gestern kam das Paket mit Netzteil und CPU-Kühler an und ich hab‘ den ganzen Spaß mal zusammengeworfen. Falls sich jemand dafür interessiert, wie die Kiste von innen aussieht, kann ich gerne mal 'n Foto knipsen, wenn später die Sonne in mein Zimmerchen scheint. Immerhin ist die CPU jetzt im Idle nur noch bei ~ 35° bei offenem Fenster und 18° Außentemperatur.Aber genug davon, der PC bootet problemlos und wie erwartet darf ich mein Festplatten-Passwort auf dem Bildschirm der RX 5700 eingeben, ebenso wie Manjaro Linux im GRUB auswählen, damit Linux dann nach der Initialisierung des „Simple Desktop Display Manager“ auf die GTX 970 wechselt und mir dort meinen Desktop anzeigt. So weit, so gut!
Ansonsten hab‘ ich IOMMU bzw. Virtualisierung in den sehr versteckten CPU-Einstellungen meines Mainboards aktiviert, den entsprechenden Kernel-Parameter gesetzt, damit IOMMU auch Software-seitig aktiviert ist, die IDs von GPU und dazugehörigem Audio-Controller ebenfalls als Kernel-Parameter gesetzt und die entsprechenden Module zum Initramfs hinzugefügt. Ich erspare euch mal die Details, wen es interessiert kann die einzelnen Schritte in der Arch Wiki nachlesen.
Tja und nach einem Reboot – ist alles beim Alten, das System bootet mit der RX 5700 und wechselt dann auf die GTX 970. Aber immerhin zeigen mir
dmesg und lspci an, dass beide Geräte erfolgreich vom vfio-Treiber gebunden wurden.Ich hab‘ dann mal diese Anleitung zu Rate gezogen, die mir @0-8-15 User in dem Kaufberatungs-Thread verlinkt hat, aber irgendwie hat auch das noch keine Früchte getragen. Ich werd‘ erstmal die VM einrichten, so wild ist es jetzt nicht, beim Booten kurz das Input des Monitors zu wechseln.
Noch 'ne Notiz am Rande, ich hab‘ mal Folding@Home angeschmissen und bei ~ 85 % CPU-Auslastung ist die CPU bei maximal 80° C.
Also, virt-manager gestartet, ein bisschen rumgebastelt, um meine zweite SSD direkt als Speichergerät zu Verfügung zu stellen (siehe unten), richtige OVMF-Firmware ausgewählt, CPU-"Netzstrutur" und "host-passthrough" manuell eingetragen, 12 von 16 GB Arbeitsspeicher hinzugefügt, als erste Boot-Option ein Windows 10 ISO, als zweite die VirtIO-Treiber und schließlich die SSD ergänzt, Netzwerk erstmal idiotensicher auch als komplettes Passthrough, weil ich vergessen habe NAT einzurichten, Maus und Tastatur ebenfalls (zur Not kann hab' ich noch 'ne zweite Maus) und natürlich die RX 5700 als PCIe-Gerät hinzugefügt.
Um eine SSD als Gerät hinzufügen zu können - weil Libvirt/virt-manager das nicht nativ unterstützt - muss man erst einen regulären Speicherpool (pool.qcow2) auf der formatierten und gemounteten SSD erstellen, den dann während der Einrichtung der VM und vor der Installation des OS wieder löschen und die SSD als Speichergerät mit
/dev/disk/by-uuid hinzufügen. Dann wird die bei der Installation als raw-Gerät erkannt, man kann erst die nötigen Treiber installieren und dann das OS.So, VM gestartet und, alles hängt, kein Bild von der RX 5700 und nur die zweite Maus und ein "Ausschalten erzwingen" konnte helfen. Ich mach' jetzt erstmal 'n Päuschen und berichte später nochmal..
EDIT #1:
Okay, ich hab' nochmal mit dem Boot-Medium rumexperimentiert (es musste wohl eine SATA CD-ROM sein) und jetzt ging's, also wenigstens über die Spice-Videoausgabe im Fenster vom virt-manager. Ich hab' zwar vergessen, welcher der richtige VirtIO-Treiber war, aber hab' dann diese hilfreiche Anleitung gefunden.
Nach der Installation von Windows 10 also noch schnell den VirtIO "Guest Agent" installiert und in dem Zuge auch gleich Firefox und die Radeon-Software. Die RX 5700 wird auf jeden Fall schon im Geräte-Manager angezeigt. Erstmal das System herunterfahren, Windows-ISO und VirtIO Treiber-Image aus der Bootreihenfolge nehmen und die SSD von SATA zu SCSI ändern. Tja und ein Neustarten der VM funktioniert dann nicht, wegen
Unknown PCI header type '127' for device '000:28:00:0'. Das ist die RX 5700 und der berüchtigte Reset Bug - großartig! Aber ich hab's ja geahnt. Ich verabschiede mich erstmal wieder für eine kurze Recherche oder mindestens einen Reboot meines Host-Systems.EDIT #2:
Fuck, ich hätte die SSD
by-id und nicht by-uuid einbinden sollen! Ersteres ist Hardware-spezifisch, zweiteres Partitions-spezifisch. Entscheidender Unterschied. Nach 'nem Reboot wird die SSD von Linux als "unformatiert" erkannt und hat eine andere UUID, als die im virt-manager hinterlegte und beim Starten der VM meckert der virt-manager berechtigter Weise, dass die SSD nicht gefunden wird. Also Windows nochmal neu installieren.EDIT #3:
Hat zwar keiner nach gefragt, aber hier ist jetzt doch mal 'n Bild von der Maschine.
Update #2 (24. April 2020):
Ich hab' jetzt die VM neu erstellt, die SSD by-id eingebunden und Windows 10 installiert und auch nach einem Neustart des Host-Systems wird die SSD korrekt erkannt und die VM bootet problemlos ins Windows. Einige SCSI- bzw. VirtIO-Treiber hab' ich bereits installiert, wie in der bereits oben verlinkten Anleitung beschrieben. Ich kann die VM aber trotzdem nicht mit der SSD als SCSI-Gerät, sondern nur als SATA-Gerät starten, sonst lande immer in der Shell. Ist aber halb so wild, Hauptsache, das System läuft erstmal und das Problem kommt auf meine To-Do-Liste.Aber zurück zu den wichtigen Dingen, der Grafikkarte! Also VM hochgefahren, die aktuellste Radeon Software installiert, Windows Updates gemacht, Host neugestartet, Gast auch neu gestartet (weil ich mich noch nicht um den Reset-Bug gekümmert habe) aber die RX 5700 wird nicht erkannt und die Radeon Software sagt mir, die Treiber seien nicht installiert.. Großartige Hilfe!
Nach kurzem Bemühen einer Suchmaschine kam ich dann drauf, mal im Geräte-Manager zu schauen, was die Grafikkarte eigentlich für 'n Gerätestatus hat und sehe den Fehlercode 43. Nach wiederum kurzer Recherche scheint das Problem mit den Kernel-Parametern zu tun zu haben, die den EFI-Framebuffer deaktivieren. Also die VM nochmal herunterfahren, diesmal mit Absturz des Linux-Hosts inklusive, neu gestartet und Kernel-Parameter geändert. Laut dem erstbesten Reddit-Post soll man
video=efifb:off statt video=efifb:off,efibf:off nutzen. In dem Zuge hab' ich auch gleich nomodeset ergänzt und alles neu gestartet, leider wieder ohne Erfolg! Vielleicht hilft ja der erste Troubleshooting-Punkt aus der Arch Wiki. Aber das schaue ich mir später mal an, nach der erfolgreichen Neuinstallation der VM war der Rückschlag gerade wieder genug für heute..Was bleibt? To-Dos!
- Fehlercode 43 der Grafikkarte
- SCSI-Treiber der Festplatte installieren
- generell den AMD Reset-Bug patchen (vielleicht hier und hier)
- Booten von der RX 5700 verhindern
Update #3 (27. April 2020):
Ich war wohl am Freitag nicht so ganz auf der Höhe und hab' den video=efifb:off-Parameter schlicht falsch eingetragen. Jetzt hat es funktioniert, der Fehlercode 43 ist verschwunden und die Grafikkarte wird richtig erkannt!Außerdem hab' ich nochmal zum Reset-Bug recherchiert und mit dem Manjaro Kernel 5.3 bzw. 5.4 LTS ist der erste von zwei Patches enthalten. Hier der Thread zum Navi Reset Kernel Patch, hier der Beitrag zum Manjaro-Kernel und hier der Beitrag zum zweiten Patch.
Ich hab' einfach mal von Kernel 5.6.7-1 auf 5.4.35-1 gedowngradet und konnte meine VM tatsächlich herunterfahren, ohne dass der Host abgestürzt ist. Ein Neustart der VM hat allerdings nicht funktioniert, die GPU scheint also immer noch nicht richtig zu resetten. Auch ein zweites Mal kann ich die VM herunterfahren und mein Linux-System stürzt nicht ab. Aber ein Blick auf
journalctl -b -p err - also alle Fehlermeldungen seit dem letzten Boot - zeigt folgende Fehlermeldungen:
Code:
Apr 27 14:22:16 TaihuLight kernel: AMD-Vi: Completion-Wait loop timed out
Apr 27 14:22:16 TaihuLight kernel: iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=28:00.0 address=0x42cda2fb0]Außerdem habe ich mal meine Spiele-Partition ebenfalls
by-id eingebunden, um nicht jedes Mal auf's neue die knapp 90 GB GTA Online herunterladen zu müssen. Das Spiel läuft auf jeden Fall butterweich auf hohen bis sehr hohen Grafikeinstellungen in 2560x1440 und ~60 Fps. Das Ziel meines ursprünglichen Upgrade-Threads hab' ich auf jeden Fall erreicht, aber das war bei der Hardware auch irgendwie klar. Ich überlege noch, wie ich am besten die Performance von Prozessor und Grafikkarte in der VM mit bare-metal-Performance vergleiche, vielleicht nehm' ich da einfach mal Test von Computerbase als Referenz.Erstmal bin ich wirklich froh, wie schnell die Einrichtung der virtuellen Maschine lief. Mal abgesehen von Recherche am Rande und ein paar "Flüchtigkeitsfehlern" war das schon fast routiniert im Vergleich zu meinem ersten Versuch, bei dem ich mir erst noch wirklich alles aneignen musste. Jetzt werd' ich mir wohl mal aneignen müssen, wie man 'n Manjaro-Kernel patched und kompiliert und denke, der Thread ist 'n guter Anfang.
EDIT #1:
Ich hab' jetzt mal 'n paar Benchmarks angeschmissen, weil es mich doch sehr interessiert, wie die VM überhaupt performt. ComputerBase hat ja eigene Test bzw. Benchmarks, sowohl vom Ryzen 5 3600, als auch von der RX 5700, die ich hier als Vergleich heranziehe.
Nochmal kurz die Infos zur VM:
Windows 10 Pro v1909 Build 18363.815
AMD Ryzen 5 3600 @3,60 GHz
12 GB G.Skill Aegis DDR4-3200, CL16
MSI Radeon RX 5700 Evoke GP OC, 8GB
Radeon Software v20.2.2
Beginnen wir mit der Grafikkarte!
Ich hab' mir Shadow of the Tomb Raider über Steam heruntergeladen, weil es in den Benchmarks von ComputerBase auftaucht, eine Trial Version zur Verfügung steht und einen eingebauten Benchmark hat. Ich hab' mich dabei an die Grafikeinstellungen des CB-Benchmarks gehalten, war aber zu faul, mir das Savegame herunterzuladen und hab' einfach den eingebauten Benchmark gemacht. Falls es jemand wirklich wissen will, lasse ich mich aber auch noch dazu überreden, exakt den CB-Benchmark zu machen, falls das mit der Trial Version überhaupt möglich ist.
Hier die Ergebnisse:
Die durchschnittlichen 65 FPS sind deutlich höher, als die 55,3 von ComputerBase, aber das kann an verschiedenen Dingen liegen, vor allem wahrscheinlich am integrierten Benchmark, das einfach nicht die tatsächliche Performance abbildet. Notiz am Rande, ich hab' auf die Schnelle diesen Artikel gefunden, der witziger Weise anhand von Tomb Raider erläutert, warum Benchmark-Tools problematisch sind. Irgendwie 'n unbefriedigendes Ergebnis, aber ich müsste nochmal nach Benchmarks von aktuellen Spielen suchen, die ich auch besitze.
So, erstmal weiter zum Prozessor:
Ich hab' einfach Cinebench R15 und R20 jeweils einmal im Multi Core-Test und einmal im Single Core-Test laufen lassen. Keine Ahnung warum, aber Cinebench R15 erkennt meinen Prozessor als 12 Kerner und mein Betriebssystem als Windows 8, aber das wird dem Benchmark ja keinen Abbruch tun.
Das sind die Ergebnisse, in den Klammern stehen die Ergebnisse von ComputerBase und die Differenz in Prozent:
Cinebench R15
CPU (Multi Core): 1499 cb (1581 cb; -5,19 %)
CPU (Single Core): 190 cb (197 cb; -3,55 %)
Cinebench R20
CPU (Multi Core): 3382 pts (3539 pts; -4,44 %)
CPU (Single Core): 465 pts (474 pts; -1,90 %)
Bis auf den realitätsfernen Grafikarten-Benchmark kann man wahrscheinlich sagen, dass die Performance relativ ähnlich ist. Laut dem Cinebench-Benchmarks ist der Prozessor im Durchschnitt keine 5% langsamer, als bei dem Benchmark von ComputerBase. Das ist aber auch nicht sonderlich verwunderlich, weil ja alle CPU-Kerne bzw. Thread und die komplette GPU durchgereicht werden.
Ich werde mich jetzt erstmal wieder dem Kernel-Patch widmen..
Update #4 (28. April 2020):
Nur ein ganz kurzes Update, aber ein großer Erfolg!Die bereits verlinkte Anleitung hat gleich in zwei Punkten nicht für mich zugetroffen. (Die Seite ist übrigens von einem Tag auf den anderen mal off- und mal online, darum oben der Direktlink und hier ein Link zum Web Archive.)
Also 1. ist der Kernel-Parameter in der Anleitung falsch bzw. ich glaube veraltet und damit redundant beschrieben (und man muss ihn richtig abtippen!) und 2. musste ich das Compatibility Support Module (CSM) ausschalten und nicht einschalten. Das CSM ermöglicht älterer Hardware das Booten mit Legacy BIOS statt UEFI. Naja, jedenfalls hab' ich es mehr aus Spaß einfach mal ausgeschaltet und siehe da, mein Computer bootet von der GTX 970! Jetzt bleibt mir endlich das nervige Display-Input wechseln nach dem Eingeben meines Festplatten-Passworts erspart und mir wird obendrein noch das schicke Mainboard-Logo und die Boot-Hotkeys angezeigt - wunderbar.
Jetzt aber versprochen als nächstes der Kernel-Patch..
Update #5 (29. April 2020):
Noch ein kleines Update, weil mir gerade zwei Dinge in den Kopf gekommen sind:Man sollte die angelegten Speicherpools, die für das Durchreichen von Festplatten bzw. Partitionen nötig sind natürlich wieder löschen. Bei mir waren das einmal eine 20 GB Datei mit der
id der SSD im home-Verzeichnis und eine entsprechende Datei auf der Partition, auf der meine Spielebibliothek liegt.Außerdem sollte man die im virt-manager hinterlegten Pfade dieser Speicherpools löschen. Das ist nicht besonders wichtig, aber verhindert zum einen eine Fehlermeldung im journalctl vom libvirtd-Service und verhindert außerdem Verwirrung beim hinzufügen von weiteren Speicherpool bzw. -geräten. Dazu muss man den virt-manager und die Konfiguration irgendeiner virtuellen Maschine öffnen, dort auf "Gerät hinzufügen" -> "Speicher" -> "Benutzerdefinierten Speicher auswählen oder erstellen" -> "Verwalten..." und dann öffnet sich die Übersicht über die "Speicherdatenträger". Hier habe ich zwei Pfade, die auf die ehemals in meinem /run/media-Verzeichnis gemounteten Festplatten verweisen und einfach gelöscht werden können.
Außerdem hab' ich (wie viele) den Ryzen-Hypetrain mitgefahren und hab' mich (ebenfalls wie viele) über die hohen Temperaturen gewundert. Mit dem Standardtakt von 3,6 GHz komme ich unter Last von ~ 85 % CPU-Auslastung durch Folding@Home auf 85° C. Nebenbei steht mein alter Intel Core i5-3570 mit Standardtakt unter 100 % Volllast durch Folding@Home bei gemütlichen 50° C in der Zimmerecke - allerdings auch ohne Gehäuse. Mit aktiviertem MSI Game Boost im BIOS und dem damit erhöhten Takt auf bis zu 4,2 GHz komme ich bei gleicher Last auf über 100° C und habe an dieser Stelle den Test abgebrochen, weil die CPU ohnehin ab 95° C drosselt. Aber warum schreibe ich das?
Einerseits möchte ich natürlich alle für Folding@Home begeistern!
Andererseits möchte ich aber vor allem auf dieses Statement eines AMD-Mitarbeiters auf Reddit aufmerksam machen, was nicht nur detailliert erklärt, wie und warum die Temperaturen zustande kommen, sondern auch, wie und mit welchen Einstellungen man seinen Ryzen-Prozessor am besten nutzt.
Ansonsten läuft meine GTX 970 auch ganz wunderbar unter Manjaro Linux und weniger anspruchsvolle Spiele wie Minecraft (mit Shadern) oder CS:GO laufen hervorragend. Und ich habe letzens noch diese Anleitung entdeckt, die erklärt, wie man mit PRIME eine Grafikkarte sowohl unter dem Host- als auch unter dem Gast-System verwenden kann. Wenn ich denn irgendwann mal den Reset Bug bearbeitet habe, juckt es mich außerdem noch in den Fingern, das auszuprobieren..
Update #6 (2. Mai 2020):
Wie könnte man ein langes Wochenende besser nutzen, als damit, das erste mal einen Linux-Kernel zu patchen, zu kompilieren und diesen dann zu installieren? Genau das habe ich gerade endlich auf meinem Manjaro Linux-System getan und möchte euch berichten, wie das funktioniert hat!Ich hab' mich vor allem an diese kurze Anleitung gehalten und die dort verlinkten Wiki-Artikel.
Zunächst sollte man nachschauen, welchen Kernel man aktuell nutzt und welche installiert sind. Das kann man mit dem Befehl
mhwd-kernel -li. In meinem Fall ist das "5.4.35-1-MANJARO" bzw. "linux54". Ich hab' mich jedoch dafür entschieden, gleich Linux 5.6 zu installieren. Damit habe ich einerseits einen aktuelleren Kernel, andererseits überschreibe ich beim Installieren nicht den aktuell installierten Kernel. Es ist immer ratsam mindestens zwei Kernel installiert zu haben. So kann man bei einem fehlerhaften Kernel immer noch auf einen stabilen Kernel zurückgreifen.Als nächstes sollte man sich vergewissern, dass man
git installiert hat und es zur Not einfach installieren:$ pacman -S gitJetzt klonen wir das Git-Repository des bevorzugten Kernels in einen neuen Ordner. Also einen neuen Ordner im
/home-Verzeichnis erstellen:# mkdir /home/arjab/buildIn das Verzeichnis wechseln:
# cd /home/arjab/buildUnd das Repository klonen:
# git clone https://gitlab.manjaro.org/packages/core/linux56.gitDabei ist wichtig,
git nicht mit sudo auszuführen, da der makepkg-Befehl später nicht als sudo ausgeführt werden darf und dann keine Schreibrechte für den Ordner hat.Jetzt sollte in dem
/build-Verzeichnis ein Ordner sein, der wie der Kernel benannt ist - also "linux56" - und zahllose Dateien enthält. Unter anderem einige *.patch-Dateien, in die sich unser Navi Reset Bug Patch einreiht.An dieser Stelle sollte man in das
/linux56-Verzeichnis wechseln:# cd ./linux56Dann hier den Text des Patches kopieren und eine neue Datei erstellen:
# nano navi.patchDen Patch einfügen, eine Zeile wie in diesem Post beschrieben ändern:
mmio = ioremap(mmio_base, mmio_size); stattmmio = ioremap_nocache(mmio_base, mmio_size);.Die Datei speichern und den Editor verlassen.
Jetzt müssen wir dem
PKGBUILD-Skript noch "mitteilen", dass er unseren Patch beim Kompilieren des Kernels auch einfügen soll. Hierzu bearbeiten wird die PKGBUILD-Datei mit: # nano PKGBUILDIn der Datei findet man unter der Zeile, die mit
source=(... beginnt eine Liste mit verschiedenen Dateien, die alle auf .patch enden. Hier fügt man eine neue Zeile ein und ergänzt den Dateinamen des Patches. In meinem Fall schlicht 'navi.patch'.Außerdem muss unter der Zeile, die mit
prepare() beginnt ebenfalls der Patch eingetragen werden:patch -Np1 -i "${srcdir}/navi.patch"Dann die Datei einfach speichern und den Editor beenden.
Da sich jetzt die Prüfsumme der
PKGBUILD-Datei durch den ergänzten Patch geändert hat, müssen wir diese neu generieren. Das kann man mit dem updpkgsums-Befehl.Nun kann man den Kernel kompilieren. Das kann bis zu einige Stunden dauern, bei ging's mit lediglich 'ner Viertelstunde relativ schnell:
# makepkg -sDanach kann man den kompilierten Kernel mit
$ makepkg -i installieren. Dabei wird quasi pacman -U für die erstellten Pakete linux.56.pkg.tar.xz und linux56-headers.pkg.tar.xz ausgeführt.Jetzt das System neu starten und wieder mit
mhwd-kernel -li überprüfen, ob der neue Kernel installiert ist.Ich hab' euch bis zu dieser Stelle übrigens erspart, jeden noch so kleinen Fehler und meine zahllosen Versuche des Kompilierens zu dokumentieren. So hat dieses Update noch mehr den Charakter einer kurzen Anleitung und wahrscheinlich wird es niemanden interessieren, wie oft ich vergeblich versucht habe
makepkg -s auszuführen.Aber vor allem sollte jetzt hoffentlich der Reset Bug gepatcht sein!
Also die virtuelle Maschine gestartet, um sie dann sofort wieder herunterzufahren. Leider spuckt
journalctl mir immer noch einige Fehlermeldungen aus, unter anderem:
Code:
02.05.20 15:32 kernel AMD-Vi: Completion-Wait loop timed out
02.05.20 15:32 kernel ahci 0000:03:00.1: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xaf7e4000 flags=0x0070]
02.05.20 15:32 kernel AMD-Vi: Event logged [IO_PAGE_FAULT device=03:00.1 domain=0x0010 address=0xaf7e4500 flags=0x0070]
02.05.20 15:32 kernel iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT device=28:00.0 address=0x42cd8aeb0]Ein erneutes Starten der VM funktioniert zwar ohne Fehlermeldung vom virt-manager, aber leider ist
journalctl währenddessen wild dabei, Fehlermeldungen ausspucken und ein Signal kommt auch nicht aus der RX 5700 - schade eigentlich!Ich werd' das Prozedere nochmal mit anderen Kernel-Versionen wiederholen und ein bisschen weiter recherchieren. Wenigstens weiß ich jetzt, wie man 'n Kernel patcht und kompiliert und dass der Reset Bug nicht so leicht zu beheben ist, wie gedacht..
Update #7 (3. Mai 2020):
Heute nochmal ein kleines, aber feines Update zum Audio der virtuellen Maschine.Tatsächlich ist es nämlich häufig relativ problematisch, das Audiosignal der VM verzögerungsfrei und in voller Qualität aus dem Ausgabegerät der Wahl zu kriegen. Außerdem besitzt man - wie auch bei Tastatur, Maus und sonstigen Peripheriegeräten - wahrscheinlich nur ein Paar Lautsprecher oder Kopfhörer, über das man je nachdem das Audiosignal von Host- oder Gastsystem hören möchte.
In meinem Fall wird die Sache noch ein bisschen schwieriger, weil ich ein USB-Audiointerface benutze, an dem sowohl meine Lautsprecher, als auch meine Kopfhörer angeschlossen sind. Natürlich könnte man einfach den USB-Anschluss an die VM weiterreichen, was aber oft viel zu hohe Latenz oder furchtbare Verzerrungen mit sich bringt. Man könnte stattdessen auch das PCI-Gerät, an das der entsprechende USB-Controller angeschlossen ist an die VM weiterreichen. Damit werden aber auch alle anderen USB-Anschlüsse an die VM weitergereicht, die mit diesem PCI-Gerät verbunden sind und meine letzte virtuelle Maschine hat sich mit dieser Lösung oft schwer getan.
Deutlich einfach ist es, das Audiosignal der virtuellen Maschine mit PulseAudio an das Host-System quasi zurückzureichen. Der Abschnitt dazu in der Arch Wiki hat mir ehrlich gesagt nicht auf Anhieb eingeleuchtet, dafür aber dieser Artikel von Passthrough Post. Seit Qemu 4.0 reicht es nämlich aus, einige wenige Zeilen in der Konfigurationsdatei der VM zu ändern. Dazu muss man die XML-Datei (am einfachsten mit nano) editieren:
# EDITOR=nano virsh edit windows10Hier müssen dann folgende Zeilen geändert werden:
Code:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
<qemu:commandline>
<qemu:arg value='-audiodev'/>
<qemu:arg value='pa,id=pa1,server=/run/user/1000/pulse/native'/>
</qemu:commandline>
</domain>Dazu installiert man sich am besten pavucontrol, um den Audiostream einstellen zu können. Und ein kurzer Test zeigt, dass der Audiostream meiner VM win10 mit der gesetzten PulseAudio-ID pa1 korrekt an mein USB-Audiointerface Steinberg UR22 weitergegeben wird:
Ich hab' während der Konfiguration übrigens die Grafikkarte aus der VM entfernt, um diese zum Testen einfach hoch- und wieder runterfahren zu können, daher die Videoausgabe über das Fenster vom virt-manager.
Andere Peripheriegeräte, wie z.B. Maus und Tastatur oder ein USB-Controller kann man übrigens problemlos als USB-Gerät an die VM durchreichen. Bei Eingabegeräten muss man sich nur darüber im Klaren sein, dass diese dann an die VM weitergereicht werden und nicht mehr für das Host-System funktionieren. Das ist vor allem wichtig, falls die VM abstürzt oder anderweitig nicht funktioniert, aber trotzdem die Eingabegeräte für sich beansprucht. Hierfür kann man entweder auf eine zweite Maus oder Tastatur, über SSH, VNC oder Software wie Teamviewer auf das Host-System zugreifen.
Update #8 (20. Mai 2020):
Die letzten Wochen hab' ich mich mit verschiedenen Dingen rumschlagen müssen, von denen ich jetzt mal gesammelt berichte. Darunter ein Bluescreen der virtuellen Maschine, die richtigen Einstellungen des SCSI-Treibers für die Festplatte und schließlich Problemen mit PulseAudio.1. Nach einem Update auf QEMU Version 5 hat mein Windows 10 mir nach dem Hochfahren einen Bluescreen mit der Fehlermeldung KERNEL SECURITY CHECK FAILURE angezeigt. Ich dachte, dass bei einem der zahllosen Abstürze meines System aufgrund des Navi Reset Bugs beim Rumexperimentieren in den letzten Tagen irgendwelche Systemdateien beschädigt wurden. Daraufhin hab' ich wie verrückt versucht, das Windows-System mit einem Installationsmedium zu reparieren, aber nichts hat funktioniert. Nach weiterer Recherche bin ich dann irgendwann drauf gekommen, dass es schlicht an QEMU liegt und man - wie in diesem Post beschrieben - nur in der CPU-Konfiguration der virtuellen Maschine das Modell von host-passthrough auf host-model ändern muss.
Hier gibt es wohl auch noch anderes Workaround über die XML-Konfigurationsdatei der virtuellen Maschine, aber das schaue ich mir bei Gelegenheit an.
2. Ähnlich abgemüht hab' ich mich mit dem fehlenden Treiber für den SCSI-Controller und hab' wirklich versucht jeden einzelnen Treiber zu installieren, aber immer ohne Erfolg. Ich weiß schon gar nicht mehr, wie ich hier drauf gekommen bin, aber es lag ebenfalls nicht an Windows, sondern der falschen Konfiguration im virt-manager. Hier hat jedes (Speicher-)Gerät einen zugehörigen Controller, entsprechend gibt es auch einen Controller Virtio SCSI 0, an dem meine beiden Festplatten angeschlossen sind. Hier war das Modell des Controllers auf Hypervisor-Standard gestellt, benötigt jedoch VirtIO SCSI um zu funktionieren. Also hab' ich das kurz geändert, es hat auf Anhieb funktioniert und der SCSI-Controller ist nicht mehr als "treiberlos" im Geräte-Manager aufgetaucht.
3. Nach diesen zwei wirklich ärgerlichen Flüchtigkeitsfehlern hat außerdem irgendwann der Audio-Stream mit PulseAudio nicht mehr funktioniert und ich hab' bis jetzt nicht verstanden, was das Problem war. Ich hab' schlicht einen entscheidenden Teil der Anleitung aus der Arch Wiki vergessen umzusetzen oder hier zu dokumentieren und irgendwie hat es bei der ersten Einrichtung trotzdem funktioniert. Darum hier der Nachtrag:
Man muss auch die /etc/libvirt/qemu.conf-Datei ändern und den eigenen Benutzernamen eintragen, damit PulseAudio weiß, an wessen Sitzung das Audiosignal gestreamt werden soll:
nano /etc/libvirt/qemu.confDann die Zeile
user = "example" auskommentieren und example durch den eigenen Benutzernamen ersetzen. Danach den Computer oder einfach den libvirtd.service neustarten:systemctl restart libvirtd.service.So langsam werd' ich leider auch zunehmend pessimistischer was den Navi Reset Bug angeht. Ich werd' gleich nochmal den Kernel 5.7 patchen und installieren, aber denke nicht, dass das funktionieren wird. Entweder ich kaufe mir auch doch noch eine RTX 2060, aber die hat weniger Leistung als die RX 5700 oder ich verwerfe das PCI-Passthrough, was wirklich schade wäre! Ich bin unschlüssig..
Update #9 (21. Mai 2020):
Ich habe gestern den Kernel 5.7 gepatcht, (in nur 19 Minuten!) kompiliert und installiert und wurde nach einem Neustart von einem schwarzen Bildschirm begrüßt. Glücklicher Weise hab' ich nicht wieder Ewigkeiten gebraucht, um das Problem zu finden und zu beheben. Es hat schlicht der proprietäre Nvidia-Grafikkartentreiber gefehlt. Also schnell die für den Kernel passende Version installiert:$ pacman -S linux57-nvidia-440xxBei der installation werden gleich alle installierten Kernel aktualisiert und nach einem Neustart bin ich auch wieder auf meinem gewohnten Desktop gelandet. Anstatt die Grafikkartentreiber manuell zu installieren, kann man das übrigens auch einfach mit nvidia-dkms automatisieren.
Wieder ist aber die viel spannendere Frage, ob der gepatchte Kernel den Navi Reset Bug beheben konnte, aber leider ist das auch dieses Mal nicht der Fall. Nach dem Herunterfahren der virtuellen Maschine ist mein Linux-Host komplett eingefroren, abgestürzt und nach kürzester Zeit wurde der Bildschirm einfach schwarz. Auch ein zweiter Versuch kam beim gleichen Ergebnis raus..
Spannend finde ich dabei aber, dass nicht die üblichen Kernel-Fehlermeldungen auftauchen - also gar keine. Vielleicht werde ich da nochmal im Thread vom Level1Tech-Forum nachfragen, ob und wie man den Absturz debuggen kann.
Trotzdem bin ich heute optimistischer was die ganze PCI-Passthrough Geschichte und den elendigen Reset Bug angeht. Doch noch eine Nvidia Grafikkarte zu kaufen erscheint mir ziemlich sinnlos und wäre auch einfach deutlich teurer, als das ganze Projekt ohnehin schon ist. Und auch ein Dual-Boot System erscheint mir wie ein fauler Kompromis. Tatsächlich gefällt mir die Situation gerade nämlich doch besser, als ursprünglich angenommen und entspricht fast meinen Vorstellungen. Mein System bootet immer und ausschließlich ein Linux-System und kein Windows kommt mir mehr als bare-metal Installation ins Haus. Aus meinem Linux-System heraus kann ich dann die virtuelle Maschine starten, zocken und dann leider in einem Rutsch und gezwungener Maßen beide Systeme herunterfahren - aber sei es drum. Tatsächlich dient das Windows Gast-System ja auch "nur" dazu, die Spiele spielen zu können, die unter Linux gar nicht laufen, wie z.B. GTA Online. Wenn ich dann in absehbarer Zukunft doch noch hinbekomme, die RX 5700 unter beiden Systemen zu verwenden, wäre die gesamte Situation noch besser, aber wahrscheinlich macht mir hier auch der Reset Bug einen Strich durch die Rechnung.
Abgesehen davon würde ich an dieser Stelle auch nochmal ein positives Zwischenfazit ziehen, wenn ich mir meine bisherige Wall of Text so anschaue! Nicht nur hat es Spaß gemacht, mal wieder einen Computer zusammenzubauen, ich hab' auch die üblichen Fehler des PCI-Passthroughs bewältigt, sei es von der richtigen Grafikkarte im "falschen" PCI-Slot zu booten oder der klassische Fehlercode 43. Außerdem hab' ich meinen ersten Kernel kompiliert und die virtuelle Maschine mit SCSI-Treibern und PulseAudio nach meine Wünschen konfiguriert. Und obwohl die Rückmeldung hier eher verhalten ist, bin ich doch auch froh drüber, diesen Erfahrungsbericht geschrieben zu haben. Was man während einer Pandemie halt so macht..
Update #10 (30. Mai 2020):
Ich möchte mich auch hier nochmal kurz dafür bedanken, dass mein Erfahrungsbericht es zu einer Notiz auf der Startseite geschafft hat! Ansonsten löchert mich gerne mit Fragen und Anregungen, ich versuche auf alles zu antworten! Gerade weiß ich auch nicht so richtig, wie's weitergehen könnte, als falls ihr noch Ideen habt, was ich noch ausprobieren könnte oder gerne mehr Hintergrundinfos zu bestimmten Themen hättet, immer her damit. Vielleicht probier' ich ja doch mal aus, die RX 5700 auf beiden Systemen zu verwenden und GTA Online unter Linux zum laufen zu bringen..Und auf Wunsch von @lokon hier meine BIOS-Version und IOMMU-Gruppen:
BIOS via dmidecode:
Code:
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 3.50
Release Date: 11/07/2019
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)Skript
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.14IOMMU-Gruppen via Skript:
Code:
IOMMU Group 0:
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
IOMMU Group 1:
00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
IOMMU Group 10:
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
IOMMU Group 11:
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
IOMMU Group 12:
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
IOMMU Group 13:
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51)
IOMMU Group 14:
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 0 [1022:1440]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 1 [1022:1441]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 2 [1022:1442]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 3 [1022:1443]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 4 [1022:1444]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 5 [1022:1445]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 6 [1022:1446]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 7 [1022:1447]
IOMMU Group 15:
03:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller [1022:43d5] (rev 01)
03:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller [1022:43c8] (rev 01)
03:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge [1022:43c6] (rev 01)
20:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
20:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
20:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01)
22:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
25:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)
25:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)
IOMMU Group 16:
26:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch [1002:1478] (rev c4)
IOMMU Group 17:
27:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch [1002:1479]
IOMMU Group 18:
28:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c4)
IOMMU Group 19:
28:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]
IOMMU Group 2:
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
IOMMU Group 20:
29:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a]
IOMMU Group 21:
2a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485]
IOMMU Group 22:
2a:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486]
IOMMU Group 23:
2a:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c]
IOMMU Group 24:
2a:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
IOMMU Group 25:
30:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51)
IOMMU Group 26:
31:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51)
IOMMU Group 3:
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
IOMMU Group 4:
00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483]
IOMMU Group 5:
00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
IOMMU Group 6:
00:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]Lutris
IOMMU Group 7:
00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]
IOMMU Group 8:
00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484]
IOMMU Group 9:
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482]Update #11 (20. November 2020):
Ich melde mich mal zurück, weil sich in letzter Zeit einiges geändert hat!Zum einen hab' ich mein komplettes System neu installiert, meine GTX 970 rausgeschmissen und PCI-Passthrough den Rücken gekehrt. Warum? Vor allem, weil GTA Online einfach hervorragend mit Lutris läuft. Zum anderen, weil ich ein rastloser Nerd bin und mich auch mal mit Wine, Proton und Lutris auseinandersetzen wollte. Nebenbei läuft Counter Strike: Global Offensive auch nativ super auf Linux.
Falls jemanden meine ambivalente Erfahrung mit Gaming on Linux interessiert, kann ich dazu gerne noch mehr Erfahrungen teilen.
Zum anderen hat Gnif, der Entwickler des Navi Reset Kernel Patches mit zwei Kollegen ein Kernel Modul entwickelt, mit dem man einerseits Grafikkarten zurücksetzen kann ohne den Kernel patchen zu müssen. Andererseits sind die neuen Grafikkarten von Nvidias RTX 3000 Serie und vom AMDs Radeon 6000 Serie weder vom Error Code 43 noch vom Reset Bug betroffen. Das behauptet jedenfalls Linus und im Fall von AMD bestätigt das Wendell von Level1Tech. Zu Nvidia konnte ich selber gerade nichts finden und auch Reddit hat noch keine Bestätigung dazu gefunden.
Also, vergesst nahezu alles, was ich geschrieben habe - juhuu! PCI-Passthrough ist gerade wahrscheinlich einfacher denn je, sofern man eine der neuen Grafikkarten besitzt. Und da es sich bei den Fehlern um Software-seitige Probleme handelt, ist davon auszugehen, dass auch ältere Grafikkarten mit einem Treiber oder Firmware-Update nicht mehr von den Fehlern betroffen sein werden. Sofern Nvidia und AMD gütig sind..
Oder man spart sich gleich die Mühe, wenn man die gewünschten Spiele in der LutrisDB oder ProtonDB findet und spielt einfach auf Linux!
Wenn ihr Rückmeldung und Fragen habt, schreibt mir gerne in die Kommentare. Ich bin immer gespannt auf den Austausch über andere Erfahrungen. Und jetzt versuche ich erstmal Red Dead Redemption 2 zum laufen zu bringen..
Zuletzt bearbeitet:
(Fixes)
