Severity: important
Tags: upstream
X-Debbugs-Cc: ludopika@gmail.com
Dear Maintainer,
Since upgrading the backports kernel from 7.1.3 to 7.1.8, the display
pipeline wedges at random after a few hours of uptime: the screen
stops
updating while the rest of the system keeps running normally (the
journal
keeps growing for hours behind the frozen image, SSH and cron still
work).
Only a reboot restores the affected CRTC reliably.
The kernel logs "[drm] *ERROR* flip_done timed out", followed by
"commit wait timed out" on the CRTC, the plane and the connector, and
by a
WARNING in dm_arm_vblank_event().
Both amdgpu devices of this hybrid laptop are affected,
independently: the
Navi 14 dGPU (0000:03:00.0, HDMI-A-1) and the Renoir iGPU
(0000:07:00.0,
eDP-1).
I have kept 7.1.3+deb13-amd64 installed and I can boot either kernel
on
demand, so the regression window is narrow and testable. I am willing
to
bisect or to test intermediate kernels if that helps.
REGRESSION WINDOW
=================
7.1.3-1~bpo13+1 good (installed 2026-07-27)
7.1.7-1~bpo13+1 --- (installed 2026-08-20, never booted,
removed 08-21)
7.1.8-1~bpo13+1 bad (installed 2026-08-21, first booted 08-23
01:33)
First boot on 7.1.8: 2026-08-23 01:34. First freeze: 2026-08-23
07:04,
5.5 hours later. Nothing else changed on the machine that day: same
firmware-amd-graphics, same mesa, same mutter, same monitors, same
workload.
EVIDENCE
========
Measured over every boot still present in the journal (41 boots,
2026-08-03 to 2026-09-20). Same hardware, same usage, and the two
kernels
overlap in time (7.1.3 was also booted on 08-27, 09-12 and 09-20):
kernel boots cumulative uptime boots with a freeze
------- ----- ----------------- -------------------
7.1.3 15 455 h 0
7.1.8 25 596 h 13
Per boot (uptime, number of "flip_done timed out" lines, delay from
boot
to the first one, and which PCI device):
kernel boot start uptime flips 1st flip device(s)
-------------------------------------------------------------------
------
7.1.3 2026-08-04 21:44 26.3h 0
7.1.3 2026-08-06 08:00 46.2h 0
7.1.3 2026-08-08 12:22 44.2h 0
7.1.3 2026-08-10 08:39 16.0h 0
7.1.3 2026-08-11 11:32 16.9h 0
7.1.3 2026-08-12 11:04 18.0h 0
7.1.3 2026-08-13 10:03 17.0h 0
7.1.3 2026-08-14 08:20 16.9h 0
7.1.3 2026-08-15 07:50 110.4h 0
7.1.3 2026-08-20 03:33 69.9h 0
7.1.8 2026-08-23 01:34 8.3h 7 5.5 h 0000:03:00.0
7.1.8 2026-08-23 12:35 100.7h 0
7.1.8 2026-08-27 19:15 30.6h 0
7.1.3 2026-08-27 18:47 0.4h 0
7.1.8 2026-08-29 01:50 25.3h 0
7.1.8 2026-08-30 03:11 27.4h 1 22.9 h 0000:07:00.0
7.1.8 2026-08-31 06:36 7.1h 3 4.3 h 0000:03:00.0
7.1.8 2026-08-31 13:40 74.4h 3 50.7 h 0000:03:00.0
7.1.8 2026-09-03 16:04 7.0h 0
7.1.8 2026-09-04 07:53 61.8h 0
7.1.8 2026-09-06 21:39 56.9h 3 52.3 h 0000:03:00.0
7.1.8 2026-09-09 13:08 59.4h 4 2.6 h both
7.1.8 2026-09-12 00:36 4.2h 11 3.1 h 0000:03:00.0
7.1.8 2026-09-12 04:45 5.5h 28 3.6 h 0000:03:00.0
7.1.8 2026-09-12 10:17 6.0h 4 3.2 h 0000:07:00.0
7.1.3 2026-09-12 16:20 72.6h 0
7.1.8 2026-09-15 16:59 81.8h 11 77.1 h 0000:07:00.0
7.1.8 2026-09-19 02:49 21.3h 12 21.2 h 0000:07:00.0
7.1.8 2026-09-20 00:05 1.8h 7 0.8 h 0000:03:00.0
7.1.8 2026-09-20 01:55 12.8h 13 12.1 h 0000:03:00.0
7.1.3 2026-09-20 14:46 ... 0
Boots shorter than one hour are omitted from the per-boot listing for
brevity (nine of them, all with zero errors, six on 7.1.8); they are
included in the summary table above.
455 hours on 7.1.3 without a single flip_done line, including three
sessions of 46, 72 and 110 hours.
KERNEL LOG
==========
Typical sequence (dGPU, 2026-09-12, kernel 7.1.8+deb13-amd64). The
same
sequence occurs on the iGPU with CRTC:95 / PLANE:62 /
CONNECTOR:109:eDP-1.
amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:85:crtc-0] flip_done timed
out
amdgpu 0000:03:00.0: [drm] *ERROR* flip_done timed out
amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:85:crtc-0] commit wait
timed out
amdgpu 0000:03:00.0: [drm] *ERROR* flip_done timed out
amdgpu 0000:03:00.0: [drm] *ERROR* [PLANE:68:plane-4] commit wait
timed out
------------[ cut here ]------------
WARNING:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:10007 \
at dm_arm_vblank_event+0xbd/0xd0 [amdgpu], CPU#6: KMS thread/2496
CPU: 6 UID: 1000 PID: 2496 Comm: KMS thread Tainted: G S \
7.1.8+deb13-amd64 #1 PREEMPT(lazy) Debian 7.1.8-1~bpo13+1
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Micro-Star International Co., Ltd. Bravo 17
A4DDR/MS-17FK, \
BIOS E17FKAMS.113 05/18/2020
RIP: 0010:dm_arm_vblank_event+0xbd/0xd0 [amdgpu]
Call Trace:
<TASK>
amdgpu_dm_atomic_commit_tail+0x1a82/0x4550 [amdgpu]
commit_tail+0xaf/0x160 [drm_kms_helper]
drm_atomic_helper_commit+0x11a/0x140 [drm_kms_helper]
drm_atomic_commit+0xb1/0xe0 [drm]
drm_mode_atomic_ioctl+0xac9/0xd00 [drm]
drm_ioctl_kernel+0xae/0x100 [drm]
drm_ioctl+0x28f/0x520 [drm]
amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
__x64_sys_ioctl+0x96/0xe0
do_syscall_64+0xea/0x640
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
---[ end trace 0000000000000000 ]---
The caller is mutter's KMS thread going through the atomic ioctl, so
this
is not an fbcon-only path. The "CPU_OUT_OF_SPEC" taint is unrelated:
it
comes from an unstable TSC on this MSI board ("TSC found unstable
after
boot, most likely due to broken BIOS"), present identically on 7.1.3.
Once a CRTC is wedged it usually stays wedged. On 2026-09-19 a
modeset no
longer helped at all: the error came back within a second of re-
enabling
eDP-1 (zero errors while the output was off, three within one second
after
turning it back on). A reboot is then the only way out -- and even
the
reboot stalls: plymouth-reboot.service times out for two minutes
trying to
modeset the stuck CRTC.
HARDWARE
========
MSI Bravo 17 A4DDR / MS-17FK, BIOS E17FKAMS.113 (2020-05-18),
legacy BIOS boot
AMD Ryzen 5 4600H with Radeon Graphics
03:00.0 Display controller [0380]: AMD/ATI Navi 14 [Radeon RX
5500/5500M /
Pro 5500M] [1002:7340] (rev c1), subsystem [1462:12ac] --
drives HDMI-A-1
07:00.0 VGA compatible controller [0300]: AMD/ATI Renoir
[1002:1636] (rev c7),
subsystem [1462:12ac] -- drives eDP-1
Displays: eDP-1 (AUO, internal) 1920x1080 @ 144.028 Hz
HDMI-A-1 (Iiyama PL2471H) 1920x1080 @ 60 Hz
extended layout, GNOME 48 / mutter 48.7 on Wayland
The machine never suspends: zero "PM: suspend entry" across all 41
boots.
This is not a resume regression.
PACKAGE VERSIONS
================
linux-image-7.1.8+deb13-amd64 7.1.8-1~bpo13+1 (bad)
linux-image-7.1.3+deb13-amd64 7.1.3-1~bpo13+1 (good)
firmware-amd-graphics 20250410-2
firmware-linux-free 20241210-2
libdrm2:amd64 2.4.124-2
libgl1-mesa-dri:amd64 25.0.7-2+deb13u1
mutter / libmutter-16-0 48.7-0+deb13u1
gnome-shell 48.7-0+deb13u2
systemd 257.13-1~deb13u1
initramfs-tools 0.148.4
Debian 13.7 (trixie), amd64, trixie-backports enabled.
Kernel command line: ro vga=normal quiet
NON-DEFAULT MODULE PARAMETERS (full disclosure)
===============================================
Two amdgpu options are set on this machine. Neither explains the
regression, but you should know about them:
/etc/modprobe.d/99-amdgpu-overdrive.conf (since 2026-03-04)
options amdgpu ppfeaturemask=0xFFF7FFFF
Present on both kernels, for five months before the first freeze.
/etc/modprobe.d/99-amdgpu-dcdebugmask.conf (added 2026-09-12)
options amdgpu dcdebugmask=0x12 (DC_DISABLE_PSR |
DC_DISABLE_STUTTER)
Added as a workaround attempt, i.e. three weeks AFTER the first
freeze.
It did not help: freezes on 09-12, 09-15, 09-19 and 09-20 all
happened
with dcdebugmask=18 confirmed active in
/sys/module/amdgpu/parameters/dcdebugmask.
Note that this parameter is NOT active when booting 7.1.3, because
that
kernel's initramfs predates the file. So the 7.1.3 boots listed
above ran
with stock DC settings and still showed zero errors.
WHAT HAS BEEN RULED OUT
=======================
- Suspend/resume: the machine never suspends (measured, see above).
- The HDMI cable: checked, and the internal eDP-1 panel freezes
too,
which no cable can explain.
- Refresh rate alone: the external display was lowered from 120 Hz
to
60 Hz on 2026-09-02. It spaced the freezes out (two full quiet
days)
but did not stop them, and afterwards the freezes moved to the
internal eDP-1 panel, which still runs at 144 Hz.
- DC_DISABLE_PSR (dcdebugmask=0x10), then
DC_DISABLE_PSR|DC_DISABLE_STUTTER (0x12): no effect, see above.
- Disabling AMD OverDrive (ppfeaturemask): no effect.
- Userspace: the freeze happens with different applications running
or
none at all, at any hour, and hits both GPUs.
One observation that may or may not be meaningful: under 7.1.8, with
the
external display connected, pp_dpm_mclk on the Navi 14 stayed pinned
at
875 MHz. Under 7.1.3, on the same setup, it drops back to 100-500 MHz
at
idle.
POSSIBLY RELATED
================
- kernel.org bug 221929 -- "amdgpu flip_done timed out", opened
2026-08.
Same signature and the same regression window: works on 7.0.12,
breaks
on 7.1.x (7.1.8, 7.1.9, 7.1.10 and 7.2 all tested by the
reporter).
- kernel.org bug 221929 -- "amdgpu flip_done timed out", opened
2026-08.
Same signature and the same regression window: works on 7.0.12,
breaks
on 7.1.x (7.1.8, 7.1.9, 7.1.10 and 7.2 all tested by the
reporter).
There the trigger correlates with a high-refresh internal panel
(360 Hz) and the freezes stop at 60 Hz.
Same signature and the same regression window: works on 7.0.12,
breaks
on 7.1.x (7.1.8, 7.1.9, 7.1.10 and 7.2 all tested by the
reporter).
There the trigger correlates with a high-refresh internal panel
(360 Hz) and the freezes stop at 60 Hz.
- Debian #1122975 and #1120890 report the same error string, but on
Lucienne iGPUs and on the 6.x series, so they may well be a
different
bug.
I have not found a candidate commit myself.
HOW I CAN HELP
==============
Both kernels are installed and I can switch between them at will, and
the
failure shows up within a few hours on the bad one. I can:
- run any 7.1.4 / 7.1.5 / 7.1.6 / 7.1.7 build you point me at,
including
from snapshot.debian.org, to narrow the window further;
- bisect upstream between v7.1.3 and v7.1.8 if you would like that;
- apply and test a patch;
- provide full journal exports, drm.debug output, or anything else.
Thanks for your work.