Open full viewer

Friday evening I did the “safe” thing: switched my default boot entry to the LTS kernel so my laptop would be more stable. Saturday morning it greeted me with a black screen instead. The likely culprit turned out to be something I’d never heard of — and it had been hiding in my logs all along, on both kernels.

What Actually Happened

Open full viewer

The sequence was boring and familiar: I switched kernels, rebooted, and the screen stayed black. No splash, no login, no cursor — just a backlit void. A hard reboot brought the display back, so my first instinct was “the LTS kernel is broken, switch back.” That instinct was wrong, and the logs proved it.

The Logs

journalctl showed one recurring display error on every single boot:

Aug 01 18:37:59 linux kernel: amdgpu 0000:03:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

The useful clue wasn’t just that the error existed — it was where it appeared:

Kernel DMCUB error observed
7.1.5-1-cachyos (mainline) 12:08, 13:11, 17:23
6.18.40-1-cachyos-lts (LTS) 18:37

The same diagnostic appeared with both kernels, at boot and mid-session. That makes a kernel-independent display-firmware or hardware interaction more plausible, although it does not prove that the kernel/amdgpu driver is uninvolved.

What the Evidence Suggests

The DMCUB error happened on mainline and LTS alike — including at 13:11 and 17:23, hours after boot, while I was just browsing. That weakens the simple explanation that one kernel alone is broken; it does not prove that the kernel or amdgpu driver is innocent. (I documented an earlier round on kernel 7.0.12 in this post.)

The most useful working hypothesis is an interaction between the display driver, the panel’s power-saving path, and AMD’s firmware — a layer below the ordinary desktop session, and one that users cannot patch directly.

DMCUB 101 — the Black Box Inside Your GPU

Open full viewer

Your GPU contains a tiny display co-processor — commonly called the DMUB (the kernel diagnostic in this incident spells it DMCUB) — that runs AMD’s display firmware. It is a black box: the driver that talks to it (amdgpu) is open source, but the firmware itself is distributed as a proprietary binary through linux-firmware, loaded at boot by the Platform Security Processor. The firmware version reported on my machine was 0x0101002B.

If the display firmware or its interaction with the driver hangs, the display engine can stop while the rest of the system keeps working. That asymmetry made this confusing: the laptop felt fine (SSH worked, fans spun), only the picture was gone.

PSR: the Power-Saving Trick That Kills Displays

Open full viewer

PSR (Panel Self Refresh) is a power-saving feature: when the screen shows a static image, the panel-side pipeline can reuse a cached frame instead of receiving every refresh. On this machine, the timing of the display error made PSR a plausible trigger, not a proven root cause. The power savings are real, but a black screen is a bad exchange.

The Fix

# One-time boot-level fix (edit the boot entry at the Limine menu with 'e')
amdgpu.dcdebugmask=0x10

In the CachyOS kernel version tested, 0x10 is the bit used to mask the PSR-related path in the Display Core debug mask. It is intended as a narrower diagnostic workaround than disabling Display Core altogether; exact behavior can vary with kernel and hardware generation, so verify the mapping for your kernel before relying on it. Compare that with the fix I used last time:

Approach What it disables Side effects
amdgpu.dc=0 (last time) Modern Display Core May remove advanced display features; hardware-dependent
amdgpu.dcdebugmask=0x10 (now) PSR-related path May increase panel idle power; kernel-dependent
LTS kernel alone Nothing specific Does not address a fault reproduced on both kernels

My earlier amdgpu.dc=0 was a sledgehammer — it disabled the modern display stack. dcdebugmask=0x10 is the narrower experiment to try first.

The Trap I Almost Walked Into

Open full viewer

Here’s the part that wasted a reboot: editing /boot/limine.conf by hand is not permanent on CachyOS. The limine-mkinitcpio-hook runs limine-entry-tool after kernel installs or upgrades, and it can regenerate the boot entries — silently discarding manual edits. My carefully-sed’ed parameter could have evaporated on the next pacman -Syu.

Persisting the Workaround

The tool documents a drop-in mechanism for exactly this case: /etc/limine-entry-tool.d/*.conf, where += appends to the kernel command line:

sudo mkdir -p /etc/limine-entry-tool.d
echo 'KERNEL_CMDLINE[default]+=amdgpu.dcdebugmask=0x10' | sudo tee /etc/limine-entry-tool.d/amdgpu-psr.conf
# If you also want a separately configured fallback entry:
echo 'KERNEL_CMDLINE[fallback]+=amdgpu.dcdebugmask=0x10' | sudo tee -a /etc/limine-entry-tool.d/amdgpu-psr.conf

The drop-in is the durable part: whenever limine-entry-tool regenerates the boot config, it has a documented source from which to re-append the parameter for entries using the default command line. It does not automatically override entries with their own KERNEL_CMDLINE[...] settings, and fallback entries may need their own fallback scope. Creating the file does not retroactively change the command line already stored in /boot/limine.conf, so inspect the generated entries and apply it for the next boot either by adding the parameter once at the Limine menu or by regenerating the entries now:

sudo cp -a /boot/limine.conf /boot/limine.conf.before-amdgpu-psr && \
sudo limine-entry-tool && \
grep -n -C 3 'dcdebugmask' /boot/limine.conf    # inspect mainline, LTS, and fallback entries

Then reboot and verify /proc/cmdline. If the local package uses a different invocation, the one-time Limine edit remains the safe fallback.

Verify After Every Update

Open full viewer

Two commands tell you whether the protection is active after any kernel or firmware update:

cat /proc/cmdline | grep amdgpu          # dcdebugmask=0x10 should be there
journalctl -b -k | grep -i dmcub          # compare with the pre-fix boot

Bottom Line

The strongest conclusion I can make is narrower: both kernels exposed the same AMD display diagnostic, so changing kernels alone was not a reliable fix. amdgpu.dcdebugmask=0x10 is a targeted PSR-related workaround to test before disabling all of Display Core, and the limine-entry-tool drop-in preserves that workaround across future entry regeneration. Confirm the result with a reboot and fresh journal before calling it solved.

Hardware: Acer Aspire AL15-42P, AMD Barcelo APU (1002:15e7), 16” 1920×1080 panel. CachyOS, linux-cachyos 7.1.5-1 / linux-cachyos-lts 6.18.40-1, linux-firmware 20260622-1, Limine 12.5.2.