Hallo,

Habe eben eine neue Videokarte installiert,
kann damit aber darktable nicht überzeugen,
opencl zu verwenden. Außerdem kommt es immer
wieder zu einem unangenehmen "Ruckeln", wo der
Computer für vielleicht eine halbe Sekunde
einfriert und dann wieder weiter macht. Die
Details sind ziemlich lange und frustrierend,
will trotzdem versuchen zuviel "rant" zu
vermeiden.

Seit geraumer Zeit gab es zwei Programme,
welche ich sehr sporadisch verwende, und die
ein seltsames Verhalten zeigten: Gimp hatte
unlesbare icons und Titelzeilen (im Fenster),
und vlc kann praktisch jedes offene XTerm zum
flimmern bringen, sodaß ein Lesen oder
Schreiben in einem Texteditor unmöglich wird,
bis vlc wieder geschlossen wird. Das Problem
wurde akut, als ich etwas von Gtk benötigte,
was zwar funktionierte, aber die genannten
Nebeneffekte noch viel schlimmer zeigte.

So habe ich Emanuele Bassi von Gnome/Gtk
kontaktiert, dessen Diagnose war, daß meine
Videokarte (nVidia Quadro K2200 von 2015) zu alt
sei (wegen der Vulkan-Version). Das fand ich
sehr enttäuschend, denn Linux im allgemeinen und
Debian im speziellen waren immer dafür bekannt,
selbst mit Hardware Marke uralt zurecht zu
kommen. Mittlerweile habe ich einige Details
dazugelernt, sodaß dieser Vorwurf an Gtk nicht
mehr ganz so schwarz/weiß richtig/falsch ist,
aber ganz vom Tisch wischen kann ich ihn
dennoch nicht.

So habe ich eine neue Video-Karte bestellt und
eingebaut: Bassi sagte, daß er gute Erfahrung
mit der AMD Radeon RX 6800 XT machte, welche
ich dann auch suchte. Davon scheint es eine
etwas neuere Version zu geben, welche sehr
ähnliche Spezifikationen, und in etwa den
gleichen Preis hat: Die 7800. Zwar kann diese
Karte PCIe v4 während meine Kiste nur PCIe 3
kann, meine Hoffnung ist aber, daß es trotzdem
irgendwie akzeptabel gehen sollte.

Es hat eine Weile gedauert, bis ich dahinter
kam, daß es besser ist, alle Spuren zu
verwischen, daß jemals eine nVidia-Karte
installiert war, und daß die amd firmware
installiert werden muß, damit die Karte auch
mehr als nur ein muh von sich gibt. Dann aber
schien alles schlagartig zu funktionieren.

Während ich bei der vorigen Karte beobachten
mußte, daß gewisse besonders überladene
Webseiten die Ventilatoren so richtig aufheulen
ließen, was erst beim Schließen der Seite
wieder aufhörte, schien es mit mit der neuen
Karte nicht mehr ganz so schlimm. Es gibt aber
immer noch viele Seiten, welche in top den load
average konstant auf 100% halten.

Die Versuche, die Gtk-Programme auszuführen
zeigten auch, daß die zuvor beobachteten
Probleme weg waren. Dann aber merkte ich das
kurze Einfrieren des Computers, was ich als
sehr störend empfinde, auch weil es das eben mit
der alten Quadro K2200 nie gegeben hat.

Das Hauptproblem aber ist nun darktable; bei
großen Fotographien (ein Foto aus meiner Kamera
kann im raw-Format schnell trotz Kompression auf
40MB und mehr kommen), sodaß es mir völlig
gerechtfertigt erscheint, wenn so ein Programm
versucht, mit openCL, die schlimmste Last auf
die GPU auszulagern. Zwar funktioniert
darktable auch ohne openCL, aber eben viel
langsamer, was bei einer brandneuen 7800er
Karte kein gutes Gefühl vermittelt. Da war
meine K2200 um einiges schneller.

Darktable kann man auch als "darktable-cltest"
aufrufen, wobei nur getestet wird, um openCL
funktioniert. Und da bekomme ich die
Fehlermeldung: "insufficient device version",
was nach den Kosten und Mühen, die neue Karte
einzubauen, auch eher frustrierende Auswirkungen
zeigte. Mittlerweile habe ich aber verstanden,
daß sich dies nicht auf die Karte bezieht,
sondern auf die Version von openCL, welche
zumindest 1.2 sein sollte bei Mesa aber nur 1.1
ist.

Ganz so klar ist dies allerdings nicht. Denn
mit clinfo erhalte ich nun zwei Platformen: die
eine heißt "Clover":

Platform Version: OpenCL 1.1 Mesa 24.2.3-1

und die andere heißt rusticl

Platform Version: OpenCL 3.0

Wie es zu diesem rusticl gekommen ist, ist mir
ein Rätsel: Zuerst hatte ich mesa-opencl-icd
installiert. Dann wurde mir empfohlen,
rocm-opencl-icd zu installieren, wobei das
vorige deinstalliert wurde. Danach schien
opencl völlig verschwunden zu sein; in clinfo
wurde der Name von der Karte nicht mehr
erkannt. So installierte ich wieder
mesa-opencl-icd, wobei, erwartungsgemäß
rocm-opencl-icd wieder entfernt wurde. Nun aber
habe ich trotzdem auch rocm als zweite opencl
Platform installiert (obwohl nun wieder
mesa-opencl-icd installiert ist). ROCm aus dem
Jenseits?

Nach langem Suchen und ein wenig Hilfe in einem
IRC, bin ich auf die Umgebungsvariable
RUSTICL_ENABLE=radeonsi gestoßen. Es hat auch
eine Weile gedauert, um dahinter zu kommen, daß
nun in den Einstellungen von darktable das als
experimentell markierte rustiCL aktiviert
werden kann und muß, doch deutet nun alles
darauf hin, daß es nun funktioniert. Allerdings
habe ich noch nicht wirklich damit gearbeitet um
Vertrauen zu fassen und das "experimental" zu
ignorieren. Beunruhigend ist eine Bemerkung vom
Januar 2024:

"Please note that the rusticl driver is
extremely alpha and I haven't seen anyone have
great results with it yet".

Und das ruckeln ist immer noch da. Bei
glxgears reicht es, mit der Maus in ein
anderes Fenster zu gehen, daß die Zahnräder
sich scheinbar einen Augenblick lang in die
Gegenrichtung drehen.

So weit ich die Lage verstehe, habe ich jetzt
nur freien Code installiert, mit der
amd-firmware als einzige Ausnahme. Alternativ
scheint es jedoch auch irgendwo einen
proprietären driver zu geben, bei dem laut
einigen alles viel besser ist, und laut
anderen, alles noch schlechter wird.

Hat irgendwer Erfahrung mit solchen Dingen?

Muß ich damit rechnen, daß mein alter PCIe
version 3 für diese Videokarte nicht mehr
ausreicht? (das motherboard kann ich nicht
austauschen, dann für diese CPU gibt es keines
mehr, und dann müßte ich bis auf die Festplatten
alles auf den Müll kippen). Und ich wollte doch
bloß ein Problem mit Gtk lösen; der Computer
tut ja ansonsten alles, was ich von ihm erwarte.

Könnte der proprietäre Treiber eine Lösung
sein, daß das Ruckeln verschwindet und
darktable auch ohne Experimente einfach
funktioniert? Wenn ja, wie kann ich zu diesem
Treiber kommen, ohne mir meine Debian
Installation zu versauen?

Und da mir die meisten Konzepte so gar nicht
geläufig sind, wäre ich auch für weitere Tips
und Aufklärungen dankbar.

Sorry für den langen post.

--
Cris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Christoph, hi.

Christoph - 28.09.24, 23:55:53 CEST:

Sorry für den langen post.

Ich hab gar keine Ahnung von dem Themenfeld Videokarte. Mir ist ein so ausführlich ausgearbeiteter Post jedoch sehr viel lieber als ein einfaches „Es geht nicht“, das es erfordert, dem Poster unter Umständen mühsam alle
Details fragend zu entlocken, um weiter zu kommen. Für mich ist es ein Zeichen von Respekt für Antwortenden, sich die Zeit zu nehmen ein Problem oder eine Herausforderung möglichst ausführlich und konkret zu
beschreiben. Daher sehe ich kein Grund für eine Entschuldigung.

Und ich nehme mir die Zeit dennoch mal Einiges dazu zu schreiben, was vielleicht weiterhilft, das Problem näher einzugrenzen oder einzuordnen. Wobei ich mich da jetzt auf das Ruckeln beziehe. Du hast ja noch andere Probleme erwähnt, zu denen ich aber noch weniger weiß.

Und das ruckeln ist immer noch da. Bei
glxgears reicht es, mit der Maus in ein
anderes Fenster zu gehen, daß die Zahnräder
sich scheinbar einen Augenblick lang in die
Gegenrichtung drehen.

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. Und zu Grafikkarten oder
Videokarten habe ich in dem Kurs bislang nichts ausgearbeitet.

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.

Ein Test dafür könnte sein, die betroffenen Prozesse mal mit einer Realtime-Priorität zu versehen, falls sie nicht ohnehin damit laufen. Das geht mit dem Befehl „chrt“ und braucht in der Regel Root-Rechte. Falls damit das Problem verschwindet, wäre das ein Hinweis auf ein Thema mit dem Prozess-Scheduling für SCHED_NORMAL / SCHED_BATCH-Prozesse, also den Prozessen mit Nice-Werten. Falls es auch mit SCHED_RR zum Ruckeln kommt,
dann wäre es noch eine Idee, den Prozessen testweise mit der SCHED_DEADLINE-Scheduling-Strategie eine Garantie zu geben. Dazu bitte die Manpage „sched(7)“ lesen, es sind weitere Parameter erforderlich, deren Bedeutung dort unter „SCHED_DEADLINE: Sporadic task model deadline scheduling“ gut visualisiert ist. 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.

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.

Könnte der proprietäre Treiber eine Lösung
sein, daß das Ruckeln verschwindet und
darktable auch ohne Experimente einfach
funktioniert? Wenn ja, wie kann ich zu diesem
Treiber kommen, ohne mir meine Debian
Installation zu versauen?

Weiß ich nicht. Ich meide die proprietären Grafiktreiber.

Zuvor würde ich es auf jeden Fall mit einem neueren Backport-Kernel versuchen, falls Du Debian 12 aka Bookworm einsetzt.

Mein aktuelles ThinkPad hat eine integrierte Radeon 780M Phoenix 3 Grafik.
Ich hab mit dem quell-offenen „amdgpu“-Treiber hier und da im Moment auch noch Probleme mit Rucklern. Interessanterweise ebenfalls in Zusammenhang
mit Video und zwar dem Stremen von Youtube (bzw. einem Piped-Proxy) via
mpv, das auf dafür yt-dlp zurückgreift. Das tritt jedoch bei weitem nicht jedes Mal auf. Gestern trat das auf, als ich nebenher noch ein Unreal 5.3 Engine-basiertes Spiel am Laufen hatte. Vielleicht ist es die Kombination
aus 3D-Aktivität und Video abspielen, die hier eine Rolle spielt.

Das sieht dann so aus:

[ 1609.100065] ------------[ cut here ]------------
[ 1609.100075] WARNING: CPU: 8 PID: 3806 at drivers/gpu/drm/amd/amdgpu/../ display/dc/dce/dmub_psr.c:221 dmub_psr_enable+0xf7/0x100 [amdgpu]
[ 1609.100466] Modules linked in: […]
[ 1609.100748] CPU: 8 PID: 3806 Comm: InputThread Not tainted 6.10.11-
amd64 #1 Debian 6.10.11-1
[ 1609.100754] Hardware name: […]
[ 1609.100757] RIP: 0010:dmub_psr_enable+0xf7/0x100 [amdgpu]
[ 1609.101068] Code: c0 75 cf 81 fb e8 03 00 00 74 1f 48 8b 44 24 48 65 48
2b 04 25 28 00 00 00 75 13 48 83 c4 50 5b 5d 41 5c 41 5d e9 54 9f 6f ce
<0f> 0b eb dd e8 90 0c 46 ce 90 90 90 90 90 90 90 90 90 90 90 90 90
[ 1609.101072] RSP: 0018:ffffa9548280b728 EFLAGS: 00010246
[ 1609.101076] RAX: 000004dc29e5f280 RBX: 00000000000003e9 RCX: 0000000000000008
[ 1609.101079] RDX: 000000000018f7f2 RSI: 000000000018ee1d RDI: 000004dc29ccfa8e
[ 1609.101082] RBP: 0000000000000000 R08: 0000000000000002 R09: ffff9e5344379600
[ 1609.101084] R10: 0000000000000007 R11: 0000000000000000 R12: ffff9e5346cae670
[ 1609.101087] R13: 0000000000000000 R14: ffffa9548280b803 R15: ffffa9548280b804
[ 1609.101089] FS: 00007f0f31c006c0(0000) GS:ffff9e5a7ee00000(0000) knlGS: 0000000000000000
[ 1609.101092] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1609.101095] CR2: 000000000829fb00 CR3: 0000000105384000 CR4: 0000000000750ef0
[ 1609.101098] PKRU: 55555554
[ 1609.101100] Call Trace:
[ 1609.101107] <TASK>
[ 1609.101111] ? __warn+0x80/0x120
[ 1609.101121] ? dmub_psr_enable+0xf7/0x100 [amdgpu]
[ 1609.101397] ? report_bug+0x164/0x190
[ 1609.101406] ? handle_bug+0x3c/0x80
[ 1609.101413] ? exc_invalid_op+0x17/0x70
[ 1609.101417] ? asm_exc_invalid_op+0x1a/0x20
[ 1609.101428] ? dmub_psr_enable+0xf7/0x100 [amdgpu]
[ 1609.101688] ? dmub_psr_enable+0xac/0x100 [amdgpu]
[ 1609.101871] edp_set_psr_allow_active+0x27b/0x3b0 [amdgpu]
[ 1609.102026] amdgpu_dm_psr_disable+0x5b/0x80 [amdgpu]
[ 1609.102174] amdgpu_dm_atomic_commit_tail+0x30a1/0x3e70 [amdgpu]
[ 1609.102310] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102313] ? generic_reg_get+0x21/0x40 [amdgpu]
[ 1609.102445] ? dc_stream_send_dp_sdp+0xc0/0xf0 [amdgpu]
[ 1609.102584] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102586] ? wait_for_completion_timeout+0x135/0x160
[ 1609.102590] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102594] ? drm_crtc_get_last_vbltimestamp+0x55/0x90 [drm]
[ 1609.102622] commit_tail+0x91/0x130 [drm_kms_helper]
[ 1609.102635] drm_atomic_helper_commit+0x11a/0x140 [drm_kms_helper]
[ 1609.102642] drm_atomic_commit+0x9f/0xd0 [drm]
[ 1609.102658] ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[ 1609.102674] drm_atomic_helper_update_plane+0xf5/0x160 [drm_kms_helper]
[ 1609.102681] drm_mode_cursor_universal+0x10e/0x270 [drm]
[ 1609.102700] drm_mode_cursor_common+0x102/0x230 [drm]
[ 1609.102716] ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 [drm]
[ 1609.102729] drm_ioctl_kernel+0xb2/0x110 [drm]
[ 1609.102747] drm_ioctl+0x274/0x4e0 [drm]
[ 1609.102762] ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 [drm]
[ 1609.102778] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]
[ 1609.102894] __x64_sys_ioctl+0x94/0xd0
[ 1609.102901] do_syscall_64+0x82/0x190
[ 1609.102905] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102907] ? do_syscall_64+0x8e/0x190
[ 1609.102910] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102912] ? syscall_exit_to_user_mode+0x77/0x210
[ 1609.102915] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102917] ? do_syscall_64+0x8e/0x190
[ 1609.102919] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102921] ? syscall_exit_to_user_mode+0x77/0x210
[ 1609.102922] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102924] ? do_syscall_64+0x8e/0x190
[ 1609.102926] ? srso_alias_return_thunk+0x5/0xfbef5
[ 1609.102928] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 1609.102932] RIP: 0033:0x7f0f548e44bb
[ 1609.102934] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00
00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05
<89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 1609.102936] RSP: 002b:00007f0f31bfe160 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 1609.102938] RAX: ffffffffffffffda RBX: 00007f0f31bfe1f0 RCX: 00007f0f548e44bb
[ 1609.102939] RDX: 00007f0f31bfe1f0 RSI: 00000000c02464bb RDI: 000000000000000e
[ 1609.102940] RBP: 00007f0f31bfe1f0 R08: 00007f0f5437ab20 R09: 0000000000000001
[ 1609.102941] R10: 000055d45856a4d0 R11: 0000000000000246 R12: 00000000c02464bb
[ 1609.102942] R13: 000000000000000e R14: 0000000000000007 R15: 000055d457998e80
[ 1609.102945] </TASK>
[ 1609.102946] ---[ end trace 0000000000000000 ]---

Keine Ahnung, was das genau bedeutet, da ich nicht genau weiß, was „dmub_psr_enable“ macht.

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. 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.

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. Ich könnte den Fehler bei Debian einreichen, aber in der Regel wäre auch da ein Bisect sinnvoll. Mir fehlt derzeit die Zeit und die Kraft dafür. Das Laptop ist noch ziemlich neu. Es gibt bekannte Firmware-Bugs
auf deren Behebung ich mittlerweile auch schon einige Monate warte. Mal
sehen, ich warte erst mal ab. Vor allem, da dieses Problem eher selten auftritt.

Insgesamt siehe ich in Bezug auf den Linux-Kernel im letzten halben Jahr, vielleicht auch Jahr ein gehäuftes Auftreten von Regressionen. Vor allem
im Bereich Standby und Ruhezustand (Zustand auf SSD/Festplatte speichern).
Ich glaube, es würde dem Kernel gut tun, das mit der Entwicklung mal
wieder etwas langsamer anzugehen, als alle 3 Monate eine neue Version raus
zu hauen. Selbst der 6.10.11 hat hier noch Probleme. Also selbst auf die dritte Stelle der Versionsnummer ist kein Verlass mehr. Ich kaufte mir ja
das neue Laptop auch, um Kernel-Bugs in Bezug auf das alte Laptop zu
umgehen. Da ging dann der Ruhezustand gar nicht mehr. Je nach Kernel-
Version mit unterschiedlichen Fehlermeldungen im Kernel-Log. Das hat auch teilweise funktioniert, der Tiefschlaf ging wieder so einigermaßen, aber
es kamen dann eben neue Probleme dazu. Ich glaube diese Problematik ist
eine Mischung aus zu wenig erfahrenen (Kernel-)Entwicklern, hoch komplexer Hardware mit großen proprietären Firmware-Blobs, die dann bitteschön unter Windows und Linux funktionieren sollen, der Vielfalt an unterschiedlicher Hardware und Kombinationsmöglichkeiten sowie der riskant schnellen Entwicklungsgeschwindigkeit in Bezug auf den Linux Kernel und anderen hardwarenahen Software-Komponenten. Das Kernel-Team in Debian dürfte ja ebenfalls überarbeitet sein, nachdem, was ich mitbekommen habe. Ich glaube
es wäre hilfreich, da insgesamt mal ein wenig das Tempo heraus zu nehmen.

Insofern kann ich Deinen Hinweis in Bezug auf alte Hardware durchaus nachvollziehen. Aber wirtschaftlich gesehen, lohnt es sich nicht, alte Hardware zu unterstützen. Und es dürfte auch schwierig sein, da dann auch für die alte Hardware ständig Tests gemacht werden müssten, inwiefern eine Änderung für eine neuere Hardware oder eine andere Änderung einen Fehler für eine ältere Hardware verursacht. Ich bin in Kontakt mit jemanden vom Hersteller meiner Laptops, Lenovo, der dort für die Betreuung der Linux Community zuständig ist. Und da heißt es auch, es sei herausfordernd
mehrere Generationen von Laptops, Docking Stationen und anderen PCs, für
die Lenovo bei speziellen Modellen Linux Support anbietet, in Bezug auf Regressionen im Blick zu behalten. Bei normalen PCs lassen die die
Komponenten ja zudem flexibel kombinieren.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Christoph.

Christoph - 29.09.24, 17:04:37 CEST:

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.

Es geht hier um die Laptop-Firmware selbst.

Zu Deinen anderen Kommentaren fällt mir im Moment nicht mehr all zu viel
ein. Es kann durchaus sein, ich finde es sogar wahrscheinlich, dass Dein
Thema mit den Rucklern eine andere Ursache hat als bei mir.

Die Unterscheidung zwischen 2D/3D ist mir bekannt. Das 3D-Zeug wäre dann
im Wesentlichen Mesa mit OpenGL- und Vulkan-Treibern. Und dann gibt es ja
noch das Video-Beschleunigungszeug. Für AMD-GPUs ist dies VA-API:

% vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/
radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 24.2.3-1 for AMD Radeon
Graphics (radeonsi, gfx1103_r1, LLVM 19.1.0, DRM 3.57, 6.10.11-amd64)
vainfo: Supported profile and entrypoints
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointEncSlice
VAProfileNone

Das könnte beim Thema Video ja auch noch mitmischen.

Naja, ich drücke Dir die Daumen, dass da noch jemand schreibt, der sich
mit deiner Fragestellung besser auskennt als ich.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 29.09.2024 schrieb Martin Steigerwald:

Ich hab gar keine Ahnung von dem Themenfeld Videokarte. Mir ist ein so ausführlich ausgearbeiteter Post jedoch sehr viel lieber als ein einfaches „Es geht nicht“, das es erfordert, dem Poster unter Umständen mühsam alle
Details fragend zu entlocken, um weiter zu kommen.

Und hier ist es zu viel Prosa und trotzdem kaum verwertbare Info.

Wobei ich mich da jetzt auf das Ruckeln beziehe.

Das liegt meist daran, daß es Probleme mit Firmware oder Treiber gibt.
Als Erstes sollte man mal da ansetzen.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 30. September 2024, 20:39:41 CEST schrieb Christoph:

Für nachvollziehbare Lösungshinweise wäre ich
ausgesprochen dankbar.

Diese beiden Pakete sind installiert?

xserver-xorg-video-amdgpu
firmware-amd-graphics


--
Gruß
Helge

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Sep 2024 18:47:09 +0200
Michael Limburg <mlimb@gmx.de> wrote:

Und hier ist es zu viel Prosa und trotzdem
kaum verwertbare Info.

Wer ist sich da so sicher,
daß ich dabei nicht kicher,
all das in Reim zu fassen?

Im jambischen Dreiheber wäre dies bestimmt noch
länger geworden. Konkrete, aber auch nur
richtungsweisende Fragen zu verwertbarer Info
beantworte ich gerne, soweit mir das möglich
ist.

Wobei ich mich da jetzt auf das Ruckeln
beziehe. Das liegt meist daran, daß es
Probleme mit Firmware oder Treiber gibt.

Als Erstes sollte man mal da ansetzen.

Wie genau tut man so etwas? Diese Firmware ist
closed code, der im kernel läuft. Wird von mir
nun erwartet, den disassembler auszupacken und
nachzusehen, was da vor sich geht? Soweit mir
bekannt, ist dies die einzige verfügbare
Version, welche von Debian so übergeben wird,
wie sie von AMD kommt.

Für nachvollziehbare Lösungshinweise wäre ich
ausgesprochen dankbar.

--
Cris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Sep 2024 20:48:32 +0200
Helge Reimer <hrnews@onlinehome.de> wrote:

Diese beiden Pakete sind installiert?

xserver-xorg-video-amdgpu
firmware-amd-graphics

Ja.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)