Public bug reported:
Summary
Both hibernate (systemctl hibernate and a direct /sys/power/state write)
and plain suspend (systemctl suspend, s2idle) fail identically on this
laptop. The system becomes unresponsive (black screen, no input
response) and requires a hard reboot (SysRq REISUB). The common failure
point in every case is the GPU (gfx_v10_0) failing to resume: its KCQ
(Kernel Compute Queue) does not come back up, and the device ends up
wedged.
This reproduces identically across Fedora 44 (kernel
7.2.7-200.fc44.x86_64) and Ubuntu 24.04 (kernel 6.14.0-37-generic), so
it does not appear to be distro-specific.
Hardware
Laptop: Dell Inspiron 3535
CPU/APU: AMD Ryzen 3 7320U ("Mendocino")
GPU: integrated, PCI ID 1002:1506
BIOS version: <paste output of: sudo dmidecode -s bios-version>
RAM: 7GB usable
Software
Kernel (Fedora): 7.2.7-200.fc44.x86_64
Also reproduced on Ubuntu 24.04, kernel 6.14.0-37-generic
cat /sys/power/mem_sleep → [s2idle] only, no deep (S3) option available at all
on this firmware
amdgpu.gpu_recovery=1 is set on the kernel cmdline
Steps to reproduce
sudo systemctl suspend (s2idle) — screen goes black, system never resumes,
requires hard reboot.
sudo systemctl hibernate — same result.
Direct kernel test, bypassing systemd entirely: echo disk | sudo tee
/sys/power/state — same result.
Also tried forcing SuspendState=freeze via
/etc/systemd/sleep.conf.d/freeze.conf — kernel still logged PM: suspend entry
(s2idle) rather than freeze, and the same hang occurred.
Relevant kernel log (hibernate attempt)
PM: hibernation: hibernation entry
PM: hibernation: Allocated 2725552 kbytes in 6.56 seconds (415.48 MB/s)
ACPI: PM: Preparing to enter system sleep state S4
PM: hibernation: Normal pages needed: 965081 + 1024, available pages: 923410
PM: hibernation: Error -12 creating image
ACPI: PM: Waking up from system sleep state S4
amdgpu 0000:03:00.0: [drm] PCIE GART of 1024M enabled (table at
0x000000F41FC00000).
amdgpu 0000:03:00.0: PSP is resuming...
amdgpu 0000:03:00.0: reserve 0xa00000 from 0xf41e000000 for PSP TMR
nvme nvme0: 8/0/0 default/read/poll queues
amdgpu 0000:03:00.0: RAS: optional ras ta ucode is not available
amdgpu 0000:03:00.0: RAP: optional rap ta ucode is not available
amdgpu 0000:03:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not
available
amdgpu 0000:03:00.0: SMU is resuming...
amdgpu 0000:03:00.0: SMU is resumed successfully!
amdgpu 0000:03:00.0: kiq ring mec 2 pipe 1 q 0
amdgpu 0000:03:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring
kiq_0.2.1.0 test failed (-110)
amdgpu 0000:03:00.0: KCQ enable failed
amdgpu 0000:03:00.0: resume of IP block <gfx_v10_0> failed -110
amdgpu 0000:03:00.0: amdgpu_device_ip_resume failed (-110).
amdgpu 0000:03:00.0: PM: dpm_run_callback(): pci_pm_thaw returns -110
amdgpu 0000:03:00.0: PM: failed to recover async: error -110
PM: hibernation: Basic memory bitmaps freed
PM: hibernation: hibernation exit
Note: Error -12 creating image (ENOMEM) occurred before the GPU resume
attempt in this specific run — hibernation aborted image creation due to
low free memory, then tried to resume already-suspended devices as part
of the abort path, which is where the GPU resume failure hit. I believe
this is independent of the GPU bug (which also reproduces on plain
suspend, where no image creation is ever attempted), but flagging it in
case it's relevant to triage.
Following repeating loop (continues every ~2s until forced reboot)
amdgpu 0000:03:00.0: Dumping IP State
amdgpu 0000:03:00.0: Dumping IP State Completed
amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
amdgpu 0000:03:00.0: [drm] Check your
/sys/class/drm/card1/device/devcoredump/data
amdgpu 0000:03:00.0: ring sdma0 timeout, signaled seq=8544, emitted seq=8548
amdgpu 0000:03:00.0: Starting sdma0 ring reset
amdgpu 0000:03:00.0: Ring sdma0 reset succeeded
amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed
Accompanied by repeated kernel stack traces through:
amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_vm_validate ->
amdgpu_cs_bo_validate -> amdgpu_bo_move -> ttm_bo_validate
Suspend (s2idle) attempt — log simply stops
Unlike the hibernate case, plain systemctl suspend produces no further
kernel log output after entry — the journal ends and nothing else is
written, with the machine unresponsive until a hard reboot:
kernel: PM: suspend entry (s2idle)
(no further lines logged; system was unresponsive and required a hard
reboot)
Additional notes
This is a fused/integrated GPU sharing power rails with the CPU (not a discrete
card), so the failing KCQ/KIQ resume path may be interacting with SMU-level
power-state handoff specific to this APU generation.
Firmware only exposes s2idle (mem_sleep shows no deep option), which may be
contributing to how often/reliably this path is exercised versus a platform
with real S3 support.
linux-firmware is fully up to date (sudo dnf update linux-firmware → "Nothing
to do").
Happy to test patches, provide a devcoredump file
(/sys/class/drm/card1/device/devcoredump/data), or gather any additional
logs/output needed.
It happens on both ubuntu and fedora please canonical solve this issue ubuntu
was my first linux distro please solve this problem.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2169634
Title:
KCQ enable failed / gfx_v10_0 resume failure (-110) after hibernate
and s2idle suspend on Ryzen 3 7320U (Mendocino)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169634/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
