Re: Videokarten Durcheinander
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
Reply to: