Ubuntu 26.04 won't suspend

Support and Help
1

Good afternoon. I’m trying to solve a mystery involving my laptop with Claude’s help; if anyone can assist me, please see the attachment.

Technical Report — Suspend/Resume Failure (s2idle) and DMCUB Errors on AMD Renoir/Lucienne APU under Ubuntu 26.04 LTS

Report date: August 2, 2026
Author: End user (assisted report)

1. Summary

After migrating the laptop from Windows 11 to Ubuntu 26.04 LTS, the lid-close suspend behavior stopped working correctly. On Windows, closing the lid suspended the system normally and opening it resumed work without issues. On Ubuntu, the same action results in a black screen with no response to keyboard, mouse, or the power button, requiring a forced shutdown (removing the battery / holding the physical power button) to power the machine back on.

An error related to the DMCUB firmware in the amdgpu driver was identified in the kernel logs as the most likely failure point, occurring both during screen transitions (screen lock / DPMS) and during real suspend (s2idle).

2. Hardware and software

Item Detail
Laptop model Dell Vostro 3525
APU AMD Ryzen (Renoir/Lucienne), PCI ID 1002:164C, subsystem 1028:0BA1
Integrated GPU AMD Radeon (Renoir), Display Core DCN 2.1
BIOS/VBIOS ATOM BIOS 113-LUCIENNE-017
DMUB firmware version 0x0101002B
Storage NVMe 2450 NVMe 512GB (also identified as HFS960G32FEH-7A10A in another firmware report)
Wi-Fi Realtek rtw88_8821ce
Operating system Ubuntu 26.04 LTS
Kernel tested 7.0.0-28-generic
BIOS status Confirmed up to date (via fwupdmgr, no pending “System Firmware” updates)
Supported sleep state s2idle only (/sys/power/mem_sleep does not expose deep)
Swap Swap file (/swap.img, 32G), not a dedicated partition

3. Diagnostic timeline

  1. Initial symptom: closing the lid caused a black screen with no response (forced shutdown required). This occurred even in simple screen-lock scenarios (HandleLidSwitch=lock), not only during real suspend.

  2. /sys/power/mem_sleep check: confirmed exclusive support for s2idle; attempting to force deep resulted in an error (Invalid argument, os error 22), confirming the hardware does not expose S3 support.

  3. Log analysis (journalctl -b -1 -p err): repeatedly identified the error:

    amdgpu 0000:04:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

    This error occurred both during screen-lock events and during the logon process (restarting systemd-logind), suggesting the problem is tied to any reinitialization of the display pipeline (DPMS, lock, resume), not exclusively to system suspend.

  4. Additional error observed (unrelated to the freeze):

    amdgpu 0000:04:00.0: psp gfx command LOAD_TA(0x1) failed and response status is (0x7)

    Occurs normally at boot with no noticeable impact — associated with an RAS (Reliability, Availability, Serviceability) module unavailable on this chip.

  5. Test 1 — kernel parameter amdgpu.dcdebugmask=0x10: applied via GRUB. Not sufficient to eliminate the DMCUB errors.

  6. Test 2 — kernel parameter amdgpu.dcdebugmask=0x600 (disables Panel Self Refresh and Panel Replay): fully resolved the freeze caused by screen lock / DPMS (lid lock, session resume via logind). Repeatedly tested with success.

  7. Test 3 — real suspend (s2idle) with HandleLidSwitch=suspend: even with amdgpu.dcdebugmask=0x600 active, real suspend via lid close still results in a resume failure (permanent black screen, requires forced shutdown). Kernel log confirms suspend entry:

    systemd-logind[1903]: The system will suspend now!
systemd[1]: Starting systemd-suspend.service - System Suspend...
systemd-sleep[5043]: Performing sleep operation 'suspend'...
kernel: PM: suspend entry (s2idle)

    No further log entries are recorded after this point — the system freezes before it can persist any information about the resume process.

  8. Test 4 — additional parameters nvme_core.default_ps_max_latency_us=0 pcie_aspm=off (targeting a possible NVMe/PCIe wake failure): tested together with amdgpu.dcdebugmask=0x600. Did not resolve the real-suspend resume failure.

4. Current state (workaround adopted)

Given the inability to fully resolve real suspend (s2idle) with the parameters tested, the user opted for a stable configuration that avoids the freeze in daily use, at the cost of giving up real suspend:

  • /etc/systemd/logind.conf:

    HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=ignore

  • /etc/default/grub (GRUB_CMDLINE_LINUX_DEFAULT):

    quiet splash amdgpu.dcdebugmask=0x600

  • GNOME Settings Daemon configured to never suspend on idle:

    org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type = 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type = 'nothing'

With this configuration, closing the lid only locks the screen (without truly suspending), and the system resumes normally when opened, with no freezes. Real suspend (s2idle) remains non-functional on this hardware.

5. Technical summary for triage

  • Affected component: amdgpu driver, DC/DMCUB subsystem, on Renoir/Lucienne APU (0x164C).
  • Trigger: any reinitialization of the display pipeline — screen lock, DPMS timeout, or entering/exiting s2idle suspend.
  • Partial mitigation: amdgpu.dcdebugmask=0x600 (disables PSR and Panel Replay) eliminates the freeze in screen-lock/DPMS scenarios, but does not resolve the resume failure during real s2idle suspend.
  • Unmitigated failure: s2idle entry succeeds, but resume fails silently — no further logs after PM: suspend entry (s2idle), suggesting the freeze occurs before log persistence, possibly within DMCUB firmware reinitialization or another component that could not be isolated with standard logging tools (journalctl, dmesg).
  • Not yet tested: alternative kernels (newer via HWE, or older), linux-firmware bisection, log capture via serial console or netconsole (needed since local logs do not survive the freeze).

6. Suggestions for further investigation (for AMD/Ubuntu teams)

  • Test with a serial console or netconsole to capture the exact moment of the resume failure, since local logs do not persist after the freeze.
  • Check whether a newer DMUB firmware version exists outside the currently distributed linux-firmware package.
  • Confirm whether this bug matches known amdgpu issues on Renoir/Lucienne related to dc_dmub_srv_log_diagnostic_data — a recurring issue reported in the Linux/AMD community for this APU generation.
2

Welcome to Ubuntu Discourse :slight_smile:

Your post was moved to its own topic for better support.

4

No, the testing I did with AI was using Claude. I tested installing the AMD drivers, configuring GRUB, and changing the laptop lid behavior (closing and opening the lid).

Here’s what’s happening: my laptop originally came with Windows, and in Windows, when I close the lid, it either suspends or hibernates normally.

However, after installing Ubuntu 26.04 LTS, it no longer behaves the same way. When I close the lid, it doesn’t suspend or hibernate like it does in Windows.

I used Claude to troubleshoot all of these issues because I couldn’t figure out what was causing the problem. Even with the AI’s help, we weren’t able to resolve it.

That’s why I decided to post a question in the community to see if anyone else has encountered this issue and might know how to fix it.

1 Like
5

Remove # before LidSwitchIgnoreInhibited=yes in /etc/systemd/logind.conf and try again.

1 Like
6

Thanks for the suggestion! I tested it, but unfortunately it didn’t help.

I uncommented LidSwitchIgnoreInhibited=yes in /etc/systemd/logind.conf and restarted systemd-logind to apply it. The login screen froze right after that (same black-screen/no-response symptom as before, had to force a reboot).

After rebooting, I checked the logs (journalctl -b -1 -p err) and found the same error we’d already identified before this test, occurring repeatedly throughout the day — not just during suspend or lid-close, but seemingly every time the screen blanks/wakes from idle:

amdgpu 0000:04:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

This error showed up dozens of times across the day (13:32, 14:21, 14:25, 14:57, 15:01, 15:09, 16:56, 16:58, 18:04, 18:11, 18:12, 18:28, 19:55, 20:11…), which suggests the DMCUB firmware communication issue happens much more often than I realized — most of the time the driver seems to recover on its own, but it fully locks up on heavier triggers like lid-close suspend or a logind restart.

So LidSwitchIgnoreInhibited doesn’t appear related to this bug — the freeze is the same underlying amdgpu/DMCUB issue as before, not something caused by inhibitors blocking the lid action.

System: Dell Vostro 3525, AMD Renoir/Lucienne APU (PCI ID 1002:164C), DCN 2.1, Ubuntu 26.04 LTS, kernel 7.0.0-28-generic. Sleep state is s2idle only. Currently mitigating the lock/DPMS freeze with amdgpu.dcdebugmask=0x600, but real suspend (s2idle) resume still fails

1 Like
7

Kernel 7.0.0-28 did not become the “best” kernel. Can you please revert your changes and try a different kernel?

8

I did it too but it didn’t work.

9

3 posts were split to a new topic: Ubuntu Studio 26.04 doesn’t hibernate