Diagram

My laptop had a weirdly specific failure mode: the first suspend worked every time, but the second one hard-froze the machine — black screen, no response to keyboard or power button, requiring a hard reset. The fix was changing one kernel parameter from amdgpu.dcdebugmask=0x10 to amdgpu.dcdebugmask=0x600. That’s six bits of difference. Here’s what each one does, why the old value wasn’t enough, and why the new value works.

The parameter, from the kernel source

The dcdebugmask module parameter is defined in drivers/gpu/drm/amd/include/amd_shared.h as an enum DC_DEBUG_MASK. Each bit disables a specific feature in AMD’s Display Core (DC): Bit Hex Kernel constant
3 0x8 DC_DISABLE_CLOCK_GATING Hardware clock gating
4 0x10 DC_DISABLE_PSR Panel Self Refresh (v1 + PSR-SU)
5 0x20 DC_FORCE_SUBVP_MCLK_SWITCH Sub-viewport mclk switch
6 0x40 DC_DISABLE_MPO Multi-Plane Offloading

The bits that actually fix the second-suspend freeze:

Bit Hex Kernel constant What gets disabled
9 0x200 DC_DISABLE_PSR_SU PSR Selective Update only
10 0x400 DC_DISABLE_REPLAY Panel Replay
11 0x800 DC_DISABLE_IPS All Idle Power States
12 0x1000 DC_DISABLE_IPS_DYNAMIC IPS except during suspend

The old value and the new value:

0x10  = DC_DISABLE_PSR                     (bit 4)
0x600 = DC_DISABLE_PSR_SU | DC_DISABLE_REPLAY (bits 9 + 10)

Both target the same subsystem — the GPU’s panel power-saving features — but at different levels.

What these features do (and who runs them)

Diagram

PSR (Panel Self Refresh) saves power by telling the panel to cache the last frame and stop sending new ones when the screen is static. PSR-SU (Selective Update) is smarter — it only sends changed regions, not the whole frame. Panel Replay is the modern successor: the panel captures frames and replays them entirely on its own.

The critical detail: all three are managed by the DMCUB — a tiny closed-source RISC-V firmware running inside your GPU, loaded at boot from linux-firmware. The kernel driver tells it what to do, but the actual state machine lives in firmware.

Why 0x10 wasn’t enough

Diagram

With 0x10, the kernel stops issuing PSR commands — but the DMCUB firmware still manages Panel Replay internally during suspend. When the firmware saves its state on the first suspend and tries to restore it on the second, something corrupts. The firmware ends up in an infinite wait for a panel response that never arrives. The display engine is dead; the rest of the system keeps running (SSH still works, fans still spin) but you can’t see anything.

Why 0x600 works

Diagram

With 0x600, both PSR-SU and Panel Replay are disabled at the firmware level. The DMCUB never saves or restores either feature’s state during suspend. It never enters the code path that corrupts. The bug still exists in the firmware — we’re just routing around it.

What you lose (nothing noticeable)

Feature Power impact
PSR-SU disabled ~0.1–0.3 W at the panel
Panel Replay disabled ~0.1–0.3 W at the panel

Combined: roughly half a watt on a system whose APU draws 15–45 W. You won’t see a difference in battery life or display behavior. Brightness, adaptive sync, and color all work exactly as before.

Applying the fix

# 1. Set the parameter (Limine drop-in — persists across kernel updates)
echo 'KERNEL_CMDLINE[default]+=amdgpu.dcdebugmask=0x600' | sudo tee /etc/limine-entry-tool.d/amdgpu-psr.conf

# 2. Regenerate boot entries
sudo limine-update

# 3. Reboot
sudo reboot

# 4. Verify after reboot
cat /proc/cmdline | grep -o 'dcdebugmask=0x600'
# Should output: dcdebugmask=0x600

Testing it

The definitive test: suspend twice in a row.

systemctl suspend    # 1st suspend → resume → desktop should work
systemctl suspend    # 2nd suspend → resume → desktop should STILL work

Before the fix, the second resume would black-screen. After, both succeed.

Check the kernel log for DMCUB errors after testing:

journalctl -b 0 --no-pager | grep -i 'dmcub\|dc_dmub'

You should see zero DMCUB diagnostic errors on a healthy boot with the fix applied.

Bottom line

The problem is a firmware bug in AMD’s closed-source DMCUB display co-processor on Barcelo APUs (Ryzen 7 7730U). The firmware corrupts Panel Replay state during the second suspend cycle. dcdebugmask=0x600 disables the two features whose state management triggers the bug, and costs less than a watt at the panel. It’s a workaround, not a root-cause fix — AMD needs to ship corrected firmware — but it turns a laptop that hard-freezes into one that works.

Hardware: Acer Aspire AL15-42P, AMD Ryzen 7 7730U (Barcelo), 16” 1920×1080 eDP panel. CachyOS, linux-cachyos-lts 6.18.42-1, linux-firmware 20260622-1, Limine.