[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1104269: linux-image-6.12.22-amd64: amdgpu flip_done and commit wait timeouts during normal use - causes session lockup



Hello again,
Some bad news. It still crashes with 6.15.5-1~exp1. Note that the kernel image was the only package I updated from experimental, to see if it would isolate the issue. 

The crash looks identical to me. From dmesg:
[ 7259.044931] amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:85:crtc-0] flip_done timed out
[ 7297.956449] amdgpu 0000:03:00.0: [drm] *ERROR* flip_done timed out
[ 7297.956453] amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:85:crtc-0] commit wait timed out
[ 7308.196321] amdgpu 0000:03:00.0: [drm] *ERROR* flip_done timed out
[ 7308.196325] amdgpu 0000:03:00.0: [drm] *ERROR* [PLANE:82:plane-7] commit wait timed out
[ 7308.417320] ------------[ cut here ]------------
[ 7308.417323] WARNING: CPU: 8 PID: 1463 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8810 amdgpu_dm_atomic_commit_tail+0x3f90/0>
[ 7308.417547] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfkill qrtr binfmt_misc nls_ascii nls_cp437 vfat fat amd_atl in>
[ 7308.417570]  realtek sha1_ssse3 usbcore watchdog nvme_core scsi_mod mdio_devres aesni_intel libphy crypto_simd i2c_piix4 cryptd nvme_keyring vi>
[ 7308.417577] CPU: 8 UID: 0 PID: 1463 Comm: systemd-logind Not tainted 6.15-amd64 #1 PREEMPT(lazy)  Debian 6.15.5-1~exp1
[ 7308.417579] Hardware name: ASRock X870 Pro RS/X870 Pro RS, BIOS 3.30 06/16/2025
[ 7308.417580] RIP: 0010:amdgpu_dm_atomic_commit_tail+0x3f90/0x4780 [amdgpu]
[ 7308.417726] Code: ff 0f 0b 48 8b 85 48 fe ff ff c6 85 28 fe ff ff 00 48 05 68 59 04 00 48 89 85 38 fe ff ff e9 bc c6 ff ff 31 f6 e9 22 c6 ff ff>
[ 7308.417728] RSP: 0018:ffffd30802a3f3b0 EFLAGS: 00010082
[ 7308.417729] RAX: 0000000000000001 RBX: 0000000000000286 RCX: 0000000000000000
[ 7308.417730] RDX: 0000000000000001 RSI: 0000000000000297 RDI: ffff8cf998780178
[ 7308.417731] RBP: ffffd30802a3f600 R08: ffff8cf95397d118 R09: 0000000000000000
[ 7308.417731] R10: ffffd30802a3f2f0 R11: ffffd30802a3f2f4 R12: ffffd30802a3f460
[ 7308.417731] R13: ffff8cf95397d000 R14: ffff8cf95397d118 R15: 0000000000000000
[ 7308.417732] FS:  00007f53fd876a00(0000) GS:ffff8d00a31d1000(0000) knlGS:0000000000000000
[ 7308.417733] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7308.417733] CR2: 000015c80012d000 CR3: 000000015025c000 CR4: 0000000000f50ef0
[ 7308.417734] PKRU: 55555554
[ 7308.417735] Call Trace:
[ 7308.417737]  <TASK>
[ 7308.417742]  commit_tail+0xac/0x160 [drm_kms_helper]
[ 7308.417749]  drm_atomic_helper_commit+0x11a/0x140 [drm_kms_helper]
[ 7308.417753]  drm_atomic_commit+0xae/0xe0 [drm]
[ 7308.417765]  ? __pfx___drm_printfn_info+0x10/0x10 [drm]
[ 7308.417777]  drm_client_modeset_commit_atomic+0x201/0x250 [drm]
[ 7308.417790]  drm_client_modeset_commit_locked+0x5a/0x160 [drm]
[ 7308.417800]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x5e/0xd0 [drm_kms_helper]
[ 7308.417804]  drm_fb_helper_set_par+0x30/0x40 [drm_kms_helper]
[ 7308.417807]  fb_set_var+0x25b/0x460
[ 7308.417810]  ? sched_clock+0x10/0x30
[ 7308.417812]  ? sched_clock_cpu+0xf/0x1f0
[ 7308.417814]  ? psi_group_change+0x1c2/0x4a0
[ 7308.417815]  ? pick_eevdf+0x76/0x190
[ 7308.417817]  ? sched_clock+0x10/0x30
[ 7308.417818]  fbcon_blank+0x28e/0x390
[ 7308.417821]  do_unblank_screen+0xc1/0x190
[ 7308.417823]  complete_change_console+0x61/0x140
[ 7308.417825]  vt_ioctl+0xf40/0x1530
[ 7308.417827]  tty_ioctl+0xe8/0x8b0
[ 7308.417828]  ? __seccomp_filter+0x42/0x500
[ 7308.417830]  __x64_sys_ioctl+0x94/0xc0
[ 7308.417832]  do_syscall_64+0x82/0x190
[ 7308.417834]  ? syscall_exit_to_user_mode+0x4d/0x210
[ 7308.417836]  ? do_syscall_64+0x8e/0x190
[ 7308.417837]  ? syscall_exit_to_user_mode+0x4d/0x210
[ 7308.417838]  ? do_syscall_64+0x8e/0x190
[ 7308.417839]  ? syscall_exit_to_user_mode+0x4d/0x210
[ 7308.417840]  ? do_syscall_64+0x8e/0x190
[ 7308.417841]  ? __sys_sendmsg+0x86/0xe0
[ 7308.417843]  ? syscall_exit_to_user_mode+0x4d/0x210
[ 7308.417844]  ? do_syscall_64+0x8e/0x190
[ 7308.417845]  ? syscall_exit_to_user_mode+0x4d/0x210
[ 7308.417846]  ? do_syscall_64+0x8e/0x190
[ 7308.417847]  ? do_syscall_64+0x8e/0x190
[ 7308.417848]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 7308.417849] RIP: 0033:0x7f53fdb168db
[ 7308.417859] 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>
[ 7308.417859] RSP: 002b:00007ffca33d07a0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 7308.417860] RAX: ffffffffffffffda RBX: 0000000000000025 RCX: 00007f53fdb168db
[ 7308.417861] RDX: 0000000000000001 RSI: 0000000000005605 RDI: 0000000000000025
[ 7308.417861] RBP: 0000000000000000 R08: 00007ffca33d0790 R09: 000055e325974758
[ 7308.417862] R10: 00007ffca33d07e0 R11: 0000000000000246 R12: 00007ffca33d0880
[ 7308.417862] R13: 00007ffca33d0878 R14: 000055e325974f70 R15: 0000000000000006
[ 7308.417863]  </TASK>
[ 7308.417864] ---[ end trace 0000000000000000 ]---


Any other suggestions?

Regards,
Leon

--
Secured with Tuta Mail:
https://tuta.com/free-email


10 Jul 2025, 21:29 by carnil@debian.org:
Hi Leon,

On Thu, Jul 10, 2025 at 09:53:44PM +0200, Leon Moser wrote:
Hello Salvatore,
I will test Debian again over the weekend and will open a new ticket
upstream if necessary. I can confirm that with kernel 6.15.4 using
Arch it is stable, zero crashes in daily use all week. I am not sure
if the cause could be something else though, Arch also has a more
recent Mesa for example.

It might be an option that you install the 6.15.5-1~exp1 from
experimental in Debian, to get an idea if 6.15.y in Debian runs as
well stable. That would be valuable to see if anything in Debian makes
the difference.

Regards,
Salvatore

--
To unsubscribe, send mail to 1104269-unsubscribe@bugs.debian.org.


Reply to: