Re: Videokarten Durcheinander
On Sun, 29 Sep 2024 11:36:05 +0200
Martin Steigerwald <martin@lichtvoll.de> wrote:
> Wobei ich mich da jetzt auf das Ruckeln
> beziehe.
> Ich gehe mal in mich inwiefern mir von meinem
> Linux Performance-Kurs halten etwas zu den
> Ruckeln einfällt. Ich vermute aber fast, dass
> dies nicht rein Prozess-Scheduler bedingt
> ist.
Ja, auch ich gehe davon aus. Ich stelle mir
vor, daß man dabei nicht einfach nur an die CPU
denken darf, und auch nicht nur an user-space
Prozesse. Zwei Stichwörter fallen mir dazu ein:
priority inversion und resource (GPU)
contention, und beides eben in kernel-space
(amdgpu).
> Eine Idee wäre mal im Kernel-Log
> „/var/log/kern.log“ bzw. „/var/log/ syslog“
> oder direkt „dmesg“ nach Meldungen vom
> Grafiktreiber oder anderen Meldungen zu
> schauen, die mit dem Ruckeln in Zusammenhang
> stehen.
Ich sehe des öftern in dmesg nach, habe aber
auch in kern.log und Xorg.0.log nachgesehen,
aber nichts gefunden.
Gtk4 betrachtet Xorg nur als "legacy". Da es
aber viele wichtige Programme gibt, die nur auf
Xorg funktionieren, ist dies nur eine
Manifestation davon, daß es Gtk egal ist,
wieviele Leute unter die Räder kommen. "Sollen
sie doch zu KDE laufen; bin kein Apostel". In
diesem Fall macht Xorg/Wayland jedoch keinen
Unterschied, denn um amdgpu scheint man nicht
herumzukommen (außer mit Software von AMD).
Apropos drivers: Als ich diese Nachricht
verfaßte, bin ich davon ausgegangen, daß rustiCL
und rocm zwei Namen für ein und das gleiche Ding
sind. Mittlerweile habe ich den Eindruck, daß
dies nicht der Fall ist, obwohl sie irgendeine
Beziehung untereinander haben, und nicht nur,
daß es sich um AMD dreht.
> Ein Test dafür könnte sein, die betroffenen
> Prozesse mal mit einer Realtime-Priorität zu
> versehen, falls sie nicht ohnehin damit
> laufen.
Es gibt da keinen user-space Prozess: Wenn das
einfriert, ist das alles: Die Ausgaben auf dem
Bildschirm, die Ausführung von Programmen, egal
was eben gerade läuft. Da es weniger als eine
Sekunde dauert und ich die Uhrzeit nur mit
Sekunden Auflösung anzeige, ist schwer zu
sagen, ob auch die Systemzeit davon betroffen
ist. Wie oben erwähnt geben ich dem driver im
kernel-space die Schuld und keinem über ps
sichtbaren Prozess (obwohl man da scheinbar
mittlerweile auch kernel-Prozesse sehen kann).
Das freeze ist einfach zu kurz.
Hm. Könnte das damit zu tun haben, daß mein
PCIe nur v3 ist, die Karte aber v4 hat (es wird
nur gesagt, daß sie v4 unterstützt, nicht, daß
sie v4 braucht)? Vielleicht nicht, wenn es bei
dir auch ruckelt, und dein laptop relativ neu
ist (also wahrscheinlich schon PCIe v4 hat).
> Ohne Kernel mit Realtime-Patches oder
> voraussichtlich Kernel 6.12, wo die dann
> offenbar drin sind, ist das aber keine
> 100%-ige Garantie, soweit ich das verstanden
> hab.
100%-ige Garantie gibt es bei Echtzeit auch
nicht (habe in einem anderen Zusammenhang und
nicht auf diesem Rechner ~10 Jahre lang RTLinux
auf embedded verwendet). Wenn alles perfekt
läuft, kann man an die 100us kommen, aber das
ist eher selten der Fall, besonders, wenn die
Anwendung etwas anspruchsvoller wird. Aber wenn
RT in main linux kommt, könnte das mit der Zeit
besser werden.
Der 6.12 sollte angeblich schon in experimental
sein, und jemand von debian auf matrix hat mir
empfohlen, diesen einzubauen. Zwar bin ich kein
Angsthase (verwende seit jeher debian sid),
aber mit so vielen verrückten Dingen bin ich
mir nicht sicher ob ich mir noch ein paar
weitere Variablen dazuholen will. Von
experimental bis sid dauert es üblicherweise
nicht gar so lang, sodaß mir diese Entscheidung
in kürze wohl abgenommen werden wird.
> So oder so würde ich erst mal warten,
> inwiefern jemand mit einer gezielter auf
> dein Thema passenden Idee antwortet. Falls
> aber nichts Anderes hilft, könntest du obige
> Tests ja mal versuchen.
Hätte gehofft, daß es mehr betroffene gibt,
welche sich damit herumquälen…
> Ich meide die proprietären Grafiktreiber.
Das ist auch meine Präferenz. Aber bei der Wahl
zwischen "geht" oder "geht nicht", bleibe ich
meist bei "geht irgendwie".
> Zuvor würde ich es auf jeden Fall mit einem
> neueren Backport-Kernel versuchen,
sorry, hatte offensichtlich vergessen zu
erwähnen, daß dies auch debian sid ist.
> Ich hab mit dem quell-offenen
> „amdgpu“-Treiber hier und da im Moment auch
> noch Probleme mit Rucklern.
Da kann ich ein wenig frisch erworbene Weisheit
weitergeben: (1) amdgpu ist nur 2D und hängt
von der firmware ab, die proprietär ist. Ohne
diese kann man AMD unter Linux gar nicht
verwenden.
Und (2): Es gibt noch 3D und all diese Sachen,
die nichts (direkt) mit Graphik zu tun haben,
wie Algebra oder KI. Und jede davon braucht
weitere Software. Gtk verwendet 3D, und
darktable verwendet Algebra (und nach der
Umstellung auf gtk4 auch 3D). amdgpu wird aber
trotzdem gebraucht. Oder amdgpu-pro, wobei ich
nicht weiß, was das ist (proprietär?).
Also: Versuche herauszufinden, welche dieser
Teile von deiner Software verwendet wird, und
welche Optionen du bei der Implementation hast.
Was dabei passieren kann ist: daß du
herausfindest, warum bei dir schon alles
funktioniert, oder, daß es noch viel besser
funktionieren könnte, oder, daß du in einer
ähnlichen Situation bist wie ich, es aber noch
nicht wußtest (und dann entschuldige ich mich
dafür).
> Das sieht dann so aus:
> [...] WARNING: CPU: 8 PID: [...]
Deine Meldungen kamen relativ kurz nach dem
Einschalten (45 Minuten). Das "Stichwort" in
deiner Meldung ist "RIP" ("rest in peace", oder
manchmal: "rest in piece". Wenn was übrig
geblieben ist). Will heißen, daß ein Prozess
von amdgpu das Zeitliche gesegnet hat. Der Rest
ist assembly code und Register, damit ein
(extrem gut) informierter Kernel-Guru erraten
kann, was tatsächlich passiert ist.
Auch ich habe 8 Zeilen gefunden, die so
aussehen, wie deine WARNING Zeile, doch viel
später, und auf 40 Minuten verteilt (deswegen
hatte ich sie vorher nicht gesehen. Zwar habe
ich auch ein RIP gefunden, das war aber schon 7
Sekunden nach dem Einschalten und hat mit cups
zu tun (das derzeit in sid von einem Paket
blockiert wird und daher nur halb installiert
ist).
> Keine Ahnung, was das genau bedeutet,
> da ich nicht genau weiß, was
> „dmub_psr_enable“ macht.
https://bbs.archlinux.org/viewtopic.php?id=295871
> Ist das einmal passiert, dann bleibt alle
> paar Sekunden der Mauszeiger für einen
> Moment stehen, sobald ich versuche, ein Video
> abzuspielen. Das ist mit Kernel 6.10.11 und
> den aktuellen Firmware-Paketen aus Debian Sid.
ja, die habe ich auch. Aber bei mir ist es
nicht nur die Maus. Und nach weniger als einer
Sekunde ist alles wieder vorbei. Also nie ein
Druck auf den Einschalt-Knopf).
> Also es scheint dann so zu sein, dass der
> Grafiktreiber sich verhaspelt hat und dann
> in einem Zustand kommt, der sich nur durch
> einen Neustart zurücksetzen lässt.
Diese Erfahrung wurde mir glücklicherweise
erspart.
> Ich hab dazu keinen Fehlerbericht erstellt.
> In der Upstream-Kernel-Community würde es
> zunächst heißen: Bau Deinen eigenen Kernel aus
> dem Git Repo von Linux. Und dann: Bisecte,
> um den Patch zu finden, der das Problem
> verursacht.
Ja, das sind mindestens einige Tage Arbeit,
wenn du dabei nicht schon viel Übung hast. Wenn
es zu einem freeze kommt, wo ich die Kiste ganz
ausschalten muß, wäre dies für mich genug
Motivation, doch den 6.11er Kernel aus
experimental auszuprobieren. Solltest du dich
dafür entscheiden, wäre eine Erzählung hier
sehr interessant.
Übrigens könntest du dir auch die Ausgabe von
clinfo ansehen. Da kommt viel mehr als nur
Sachen über openCL. Und wenn du da was
interessantes findest, würde ich mich freuen.
> Es gibt bekannte Firmware-Bugs auf deren
> Behebung ich mittlerweile auch schon einige
> Monate warte.
firmware? da muß man auf AMD warten. Werden da
auch workarounds erwähnt? Habe nach von AMD
bekannten (und anerkannten) bugs gesucht; sie
werden erwähnt, kann sie aber nirgends finden.
> Ich glaube diese Problematik ist eine
> Mischung aus zu wenig erfahrenen
> (Kernel-)Entwicklern, hoch komplexer
> Hardware mit großen proprietären
> Firmware-Blobs…
Zur Entwicklung hätte ich vieles zu sagen, aber
das hat mit der Lösung meines Videokarten
Durcheinanders nicht mehr viel zu tun. Und da
ich weiß, daß wir das ebenso wenig richten
können, wie man die Rechtschreibreform von 1992
korrigieren kann, ist das nicht so schlimm.
Reply to: