GPU-Reset (AMD)

Dass ich mit lokalen KI-Modellen experimentiere ist ja kein Geheimnis. Zuweilen hängt sich jedoch bei diesen Experimenten die Grafikkarte komplett auf, was in der Regel einen Neustart erfordert. Der Bildschirm friert entweder komplett ein oder die GPU läuft in einer Schleife auf 100% Last, wobei der verantwortliche Prozess schon lange beendet ist.

Ich verwende eine AMD-GPU (genauer: eine Radeon RX 7900 XTX), die aus mir bisher nicht bekannten Gründen gerne zu solchen Verhaltensweisen neigt. Es scheint ein Software-Problem zu sein, denn das Problem tritt normalerweise nicht auf - ausschließlich bei KI-Prozessen, die über ein spezielles Framework abgebildet werden.

Da die GPU in so einem Szenario wahlweise komplett jegliche Grafikausgabe einfriert oder die GPU-Last GUI-Prozesse so unbenutzbar machen, dass ein Neustart des Systems als die bessere Lösung erscheint, suchte ich nach einer Möglichkeit, das System anderweitig wiederzubeleben. Ich fand eine.

Der folgende Befehl setzt die komplette GPU-Umgebung komplett zurück. Das hat zwar zur Folge, dass die graphische Benutzerumgebung komplett mit abstürzt (und damit auch alle Anwendungen, die darunter gestartet waren), jedoch kommt danach der Anmeldebildschirm wieder hoch und man kann direkt weiter arbeiten oder den Fehler suchen.

sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover

Das Ganze funktioniert selbstverständlich nur mit AMD-Grafikkarten, ob ein Nvidia-Äquivalent existiert weiß ich nicht.

Da der Befehl in den meisten Fällen nicht mehr über den Client direkt eingegeben werden kann (selbst ein Wechsel auf andere virtuelle Konsolen hilft oft nicht), ist es am einfachsten, sich einfach via SSH auf den betroffenen Host zu verbinden (über ein Notebook, ein Tablet, ein Handy, etc.) und den Befehl dort einzutippen.

Langsames Booten

Manchmal kommt es zu seltsamen Verhaltensweisen, deren Ursache sich nur schwer erahnen lässt. So auch mit dem Phänomen, dass mein Fedora 40 seit dem 1&1-Desaster ungefähr anderthalb bis zwei Minuten brauchte, um zu booten. Was war da los?

Fehlersuche

Mittels systemd-analyze critical-chain stellte sich der Dienst NetworkManager-wait-online.service als Übeltäter heraus, der fast eine Minute lang nichts tat und den Systemstart aufhielt.

Aber tat er wirklich nichts? Ein wenig Recherche brauchte zutage, dass dieser Service genau das tat, was der Name vermuten lässt. Er stellt die im NetworkManager (entweder über die integrierte GUI des Window Managers oder via nm-connection-editor) konfigurierten Netzwerkverbindungen her und überprüft, ob sie online sind. Offensichtlich nimmt er das wörtlich, eine Verbindung alleine reicht nicht aus, die Verbindung muss “nach draußen” kommunizieren können.

Wieso ist das ein Problem? Nun, ich habe drei Netzwerk-Interfaces konfiguriert. Zwei davon sind kabelgebundene Verbindungen zu meinem Switch (2.5G und 10G), die dritte ist eine WLAN-Verbindung. Letztere stellte sich als das Problemkind heraus. Ich hatte übergangsweise ja das WLAN des Nachbarn mitbenutzen dürfen, bis mein Internetanschluss wieder funktionierte. Die Gegenstelle war eine Fritzbox-Gastnetzwerk mit aktiviertem Captive Portal. Verband der NetworkManager sich nun mit dem Netzwerk, erwartete die Fritzbox einen Klick auf “okay” im Browser, der natürlich nicht kam. Die Verbindung wurde nicht freigegeben und der NetworkManager-wait-online-Dienst wartete vergeblich, bis er in ein Timeout lief.

Fehlerbehebung

Über den nm-connection-editor entfernte ich die sowieso nicht mehr benötigte WLAN-Verbindung zum Nachbarsnetz, startete neu - und siehe da, nach weniger als einer halben Minute begrüßte mich die GUI.

Vortex und .NET 8

Irgendwann in den letzten Monaten (Stand: Mitte 2024) müssen die Entwickler des Modding-Frameworks Vortex, das zur Nexusmods-Webseite gehört, entschieden haben, den Support für Windows 7 und 8.1 endgültig einzustampfen. Die neueren Versionen von Vortex benötigten fortan das .NET Framework in Version 8.x, die ausschließlich für Windows 10 und später verfügbar ist. Aus meiner Sicht eine zu begrüßende Entwicklung, denn sowohl Windows 7 als auch Windows 8.1 sind schon seit Jahren EOL (end-of-life) und werden nicht mehr mit Updates versorgt. Teile der Gaming-Szene schwören leider nach wie vor auf Windows 7, was zu einem hohen Risiko für die so betriebenen Systeme führt.

Nun verwende ich Lutris, um Spiele und Windows-Tools unter Linux schmerzfrei betreiben zu können, sofern es keine Spiele sind, die sowieso via Steam mittels Proton unter Linux laufen. Der Lutris-Installer, der für Vortex alle wichtigen Einstellungen automatisch vornimmt und ein praktisches Hilfsscript implementiert, das mittels Symlinks alle gefundenen Steam-Spiele auch unter Vortex auffindbar macht, installiert Lutris allerfings im Windows 7-Modus, der es nicht erlaubt, .NET in Version 8 zu installieren. Zudem sind die Tools, mit denen die wine-Installation, über die Vortex Linux-tauglich gemacht wird, stand Mitte 2024 etwas veraltet und kennen die .NET 8.x-Versionslinie teilweise noch gar nicht. Doch war tun, wenn man weiterhin seine Spiele komfortabel modden möchte?

winetricks aktualisieren

Bevor wir zur Tat schreiten und die winetricks auf eine Version von Anfang 2024 heben, müssen wir zuerst die emulierte Windows-Version für Vortex in Lutris anheben. Dies kann man entweder über die Kommandozeile tun oder Lutris selbst verwenden. Da wir die Kommandozeilenversion später noch verwenden, nehmen wir hier die Lutris-Version, um beide Methoden aufzuzeigen.

Nachdem wir Vortex in Lutris angewählt (nicht gestartet, nur markiert) haben, klicken wir unten am Bildschirmrand auf das kleine Joystick-Symbol und wählen “Wine-Konfiguration” aus. Ein Fenster öffnet sich, in dem wir die Windows-Version unten rechts auf “Windows 10” anpassen. Ein Klick auf “OK” - fertig.

Als nächstes installieren wir eine aktuelle winetricks-Version. Das Schöne ist: Sie muss nicht identisch mit der verwendeten wine-Version sein, für die wir sie verwenden. Für Vortex habe ich derzeit die Version wine-ge-lol-8-27 im Einsatz, die zum heutigen Zeitpunkt relativ aktuell ist. Die aktuellste winetricks-Version nebst Installationsanleitungen findet sich im zugehörigen git-Repository . Dort laden wir einfach die aktuellste Release-Datei (je nach Vorliebe als zip oder tar.gz) herunter und entpacken diese. Danach wechseln wir in das entpackte Verzeichnis, installieren das Tool mittels sudo make install und schließen danach die Konsole. Danach öffnen wir eine neue Konsole und vergewissern uns via winetricks --version, dass der Zeitstempel dem heruntergeladenen entspricht.

Ab hier ist es quasi nur noch eine Fingerübung, das Paket dotnetdesktop8 im Vortex-Prefix zu installieren. Da über die winetricks-gui von Lutris trotz des Hakens bei “Nutze winetricks des Systems” zuweilen der .NET 8.x-Eintrag zu fehlen scheint, erledigen wir das schnell über die Kommandozeile. Vorher besorgen wir uns noch den Prefix für Vortex, indem wir Vortex rechtsklicken und die Logs anzeigen lassen. Dort sollte bei einem erfolgreichen Start von Vortex der komplette Programmaufruf festgehalten sein, wobei uns der letzte Teil interessiert. Bei mir sieht er etwa so aus: /mnt/Games/vortex-mod-manager/drive_c/Program Files/Black Tree Gaming Ltd/Vortex/Vortex.exe und wir erkennen den Prefix-Pfad: /mnt/Games/vortex-mod-manager Dieser Pfad wird bei normalen Systemen vermutlich eher auf einen Unterordner des home-Verzeichnisses zeigen, aber er ist immer relativ gut erkennbar. Da wir den Pfad jetzt kennen, können wir mit einem simplem Befehl das .NET Framework aktualisieren:

WINEPREFIX=/mnt/games/vortex-mod-manager winetricks dotnetdesktop8

Die WINEPREFIX-Variable am Anfang ist essenziell, da ohne diese Angabe der Standard-wine-Prefix des Systems genutzt werden würde, der auf Vortex oder irgendeins der unter Lutris verwalteten Tools und Games keinerlei Auswirkung hätte.

Nun lässt sich Vortex starten, alle Integrationen arbeiten wieder und auch ein Aktualisieren auf die aktuellste Version funktioniert!

Happy modding!