[Laptop 13] Display never comes back after resume when the external monitor was attached while suspended (AMD Ryzen 7040, BIOS 03.20, dcn31_program_compbuf_size REG_WAIT timeout)

[dadofsambonzuki]

System Model or SKU

Framework Laptop 13 (AMD Ryzen™ 7040 Series)

BIOS Version

03.20 (INSYDE Corp., 06/23/2026). Board FRANMDCP07, product name Laptop 13 (AMD Ryzen 7040Series). This is the current release for the 7040 series.

DIY Edition Information

Memory: MemTotal 63,572,192 kB (~60.6 GiB), 2/2 slots populated. DIMM part numbers not captured.
Storage: WD_BLACK SN850X 2000GB (NVMe, /dev/nvme0n1), btrfs root.

Port/Peripheral Information

Peripheral vendor and name:

1. Philips 34E1C5600HE docking monitor, 3440x1440@100 Hz, attached by its own USB-C cable (DisplayPort Alt Mode). The monitor's internal hub is a VIA Labs USB2.0 hub (2109:2817) and enumerates at 480M, i.e. the monitor's "USB-C Setting" is the 4-lanes-to-video ("High Resolution") option, not "High Data Speed".
2. Nothing else of note on the video path.

The monitor is attached on the Linux typec port named port3 (partner present, laptop is the power sink, so the monitor is also supplying power). No alternate-mode entries are registered for any port on this system, so I cannot report the DisplayPort mode VDOs. I do not have a confirmed map of Framework port numbers 1-4 for this capture.

Standalone Operation

Full System, Standalone mode NOT enabled (normal usage)

Describe the Bug

Resuming from sleep with the external display attached that was not attached when the machine went to sleep leaves the display dead and the session unusable. Nothing recovers it: switching output state, unplugging the cable, or waiting. The result is a power-button reset.

The machine is not hard-locked - userspace keeps running for 23 minutes after the failure (journald, NetworkManager, UPower and the compositor's idle heartbeat every 5 s all keep logging) - but no output ever lights up: the internal panel stays dark too, so the session is unreachable. Only a power reset gets the machine back.

The only kernel-side signature is a display-core register timeout at the moment of resume:

Sep 30 07:20:37 framework13 kernel: amdgpu 0000:c1:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:142

dcn31_hubbub.c:151 WARNING at dcn31_program_compbuf_size+0xd0/0x220 follows in other instances. The GPU is a Radeon 780M on 1002:15bf rev c4, display core DCN 3.1.4, Display Core v3.2.384, amdgpu 3.64.0.

Two further symptoms in the same 25-second window: the monitor's hub port fails to enumerate (usb 7-1.4: Device not responding to setup address, device not accepting address 24, error -71), and the Chromium browser process aborts 14 s after the resume (SIGTRAP, si_code: SI_KERNEL, saved RIP inside a compiler-emitted int3;ud2 trap fragment in its GTK/GLib main loop). Chromium on this machine has also aborted its GPU process at an identical trap instruction right after [gfxhub] page fault → ring gfx_0.0.0 timeout → ring reset on 2026-09-18, so I read the Chromium abort as a downstream effect of the display/GPU state, not a separate bug.

Steps To Reproduce

1. Boot with the external display attached. Both outputs work (internal eDP-1 plus DP-3).
2. Unplug the display. Log: usb 7-1: USB disconnect ... and monitorremoved connector=DP-3.
3. Let the machine enter suspend (lid close) with only the internal panel attached. In the run documented here, that was at 22:35; the display had been unplugged at 21:22.
4. While the machine is suspended, plug the display back in.
5. Open the lid to resume.

Observed: the display core logs the dcn31_program_compbuf_size REG_WAIT timeout, the dock's USB tree enumerates, the compositor is told monitoradded connector=DP-3 - and no output comes up. Unplugging the cable at that point (monitorremoved, logged at 07:20:59) does not bring anything back. The display core never recovers; a power-button reset is required.

The equivalent hibernate (S4) cycle behaves the same way on this machine.

Expected Behavior

Resuming with a display attached that was not present at suspend should bring that output up (or at least leave the session usable on the internal panel), as it does when the display is attached across the whole sleep.

Screenshots

Not applicable - the failure is a dead output, so there is nothing to capture.

Operating System

Omarchy (Arch Linux), Hyprland on Wayland. Hibernation via btrfs swapfile, resume=/dev/mapper/root resume_offset=..., suspend-then-hibernate configured through upower.

Linux Kernel Version

Linux 7.2.3-arch1-3 #1 SMP PREEMPT_DYNAMIC Sun, 06 Sep 2026 13:01:04 +0000 x86_64 GNU/Linux

Additional Context

Logs (kernel + journal windows, all personal identifiers redacted):
https://gist.github.com/dadofsambonzuki/1afe511272789723e69f523dc25f02c5

Observed pattern - this is the failing configuration, and it is the change of sink set that breaks, not resume as such:

When	Configuration	Result
2026-09-30 07:20	display unplugged at 21:22, suspended at 22:35 with only eDP attached, display plugged in while suspended, resume on lid open	display dead, session unusable, power-button reset
2026-09-28 17:59	display attached across the whole hibernate (S4), resume	fine - dock re-enumerates, DP-3 comes up, monitor profile applied
2026-09-29 07:38	display attached across the sleep, resume	fine

Ruled out on this machine:

• PSR: every connector reports PSR support 0 (DC PSR ver -1 for DP-1..DP-8), so amdgpu.dcdebugmask=0x10/0x12 is not the relevant lever here.
• DSC / link bandwidth: 3440x1440@100 needs ~16.3 Gbps of raw link and 4-lane HBR3 supplies ~25.9; the log says pre_validate_dsc: MST_DSC dsc precompute is not needed. No MST in this path either - it is a single DP Alt Mode sink.
• Monitor lane-mode/OSD setting: the monitor's hub enumerates at 480M, i.e. the port is already configured for 4 lanes to video.
• Firmware version: BIOS is already 03.20, the current release for this mainboard.
• Resource exhaustion: no oom-killer events, ample free memory and swap.

The same warning also fires on a plain cold boot on this machine, through the framebuffer-removal path, so the code path is reachable in this setup:

07:44:35 amdgpu: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
07:44:35 WARNING: .../display/dc/hubbub/dcn31/dcn31_hubbub.c:151 at dcn31_program_compbuf_size+0xd0/0x220
        Workqueue: events drm_mode_rmfb_work_fn
        dcn20_optimize_bandwidth -> dcn31_program_compbuf_size
        dc_commit_state_no_check -> dc_commit_streams -> amdgpu_dm_atomic_commit_tail
        drm_atomic_helper_commit -> drm_framebuffer_remove -> drm_mode_rmfb_work_fn

The hibernate path on this machine also logs amdgpu suspend/VM-teardown warnings at resume (from the log bundle): WARNING: drivers/gpu/drm/ttm/ttm_resource.c:235 at ttm_resource_add_bulk_move (via amdgpu_device_evict_resources -> amdgpu_device_suspend -> amdgpu_pmops_freeze) and WARNING: lib/list_debug.c:62/65 at __list_del_entry_valid_or_report (via amdgpu_vm_fini -> amdgpu_vm_pt_free_root -> amdgpu_driver_postclose_kms -> drm_release). Included because the driver's own save/restore path is already misbehaving on this machine; there is an upstream report for that class (drm/amd#5517).

Upstream cross-references - the same dcn31_program_compbuf_size timeout with an unrecoverable display is already reported for other AMD platforms, so this may belong with them:

• drm/amd#5541 - "Display hang (REG_WAIT timeout in dcn31_program_compbuf_size) via USB4 dock MST, requires hard reset" (open; Rembrandt/DCN 3.1.2, dock with MST+DSC - no MST or DSC in this report)
• drm/amd#5733 - Hawk Point APU, USB-C dock hotplug: same REG_WAIT warning, then a NULL dereference in ttm_lru_bulk_move_tail(), full freeze (closed)
• drm/amd#5517 - TTM bulk_move corruption during the hibernation freeze path, deadlock ~100 min later (closed)
• drm/amd#5708 - Phoenix Radeon 780M: hibernate hangs only when a KMS client owns the display (open)
• bugzilla.kernel.org #200531 - REG_WAIT timeout ... dcn31_program_compbuf_size, reported on Framework Laptop 13 (AMD Ryzen 7040 Series)

Workaround observed so far: keep the sink set unchanged across the sleep - attach the monitor after the resume has settled, or leave it attached for the whole suspend. That has not failed yet.

[dadofsambonzuki]

Additional data from the same machine, from a full journal review rather than the single window quoted above. Kernel 7.2.3-arch1-3, linux-firmware 20260810-2, Mesa 26.2.2, DMUB 0x08005E00, SMU fw 76.102.0 (76.102.0), display core DCN 3.1.4.

The timeout is chronic on this machine, not resume-specific

dcn31_program_compbuf_size REG_WAIT timeout, whole journal (oldest entry 2026-09-10):

Day	count	Day	count
Sep 10	12	Sep 19	9
Sep 11	18	Sep 20	10
Sep 12	6	Sep 21	12
Sep 13	7	Sep 22	10
Sep 14	12	Sep 23	4
Sep 15	24	Sep 24	5
Sep 16	10	Sep 28	3
Sep 17	11	Sep 29	3
Sep 18	5	Sep 30	5

166 occurrences in total. The only gap is 25-27 Sep, which was a single boot (24 Sep 19:33 -> 27 Sep 18:37) that stayed suspended with no activity, so the count tracks display work, not wall-clock.

Most of these are harmless - nothing visibly breaks - so on its own this is not proof of causation for the dead output. What it does show is that the failing code path is trivially reachable on this machine without any suspend: on 30 Sep, in a boot with no suspend at all (boot at 07:44:31), it fires at 07:44:35 (with WARNING), 07:51:47, 07:57:13, 07:57:21. That should make it easy for anyone to reproduce the warning itself, and it argues against treating the warning purely as a resume-path artefact.

The WARNING has been observed from two different callers, i.e. not one path:

• CPU#12: Hyprland/1471 - 2026-09-28 18:17:38
• kworker/14:2, via drm_mode_rmfb_work_fn - 2026-09-30 07:44:35

Downstream

11 s after the 30 Sep 07:20:37 instance (the resume this report is about) the Chromium browser process aborted - SIGTRAP, si_code: SI_KERNEL, saved RIP on a compiler-emitted int3;ud2 trap fragment in its GTK/GLib main loop, i.e. a deliberate in-process abort rather than a memory fault. On 18 Sep its GPU process aborted at an identical trap instruction ~2 s after [gfxhub] page fault -> ring gfx_0.0.0 timeout -> ring reset. Same reading as above: correlated with the display/GPU state, not a separate application bug.

I can capture drm.debug=0xe traces around a resume with the display attached while suspended, or give exact per-occurrence timestamps, if either would help.