Just confirming that, for me, this issue is fixed as of 6.15.
Yeah it’s been a little frustrating, they JUST fixed the last bug in mesa that was breaking suspend and now we have another one a month later… I understand this is not really Frameworks fault, but does make me wonder about AMD GPU’s. I have similar issues on my desktop GPU as well.
yeah indeed, I’ve had this framework 13 going on two years now and I swear hibernate/suspend has broken 5 or 6 times through kernel regressions. it’s my first exposure to amd gpu’s on linux and it has been extremely annoying. Though nvidia hasn’t been much better TBH, the only flawless thing has been my intel GPU.
I can report similar issues. Never had this issue on my old intel based laptops but I also got those used so I don’t know if that is normal growing pains I just bypassed by using older stuff or there is something especially weird about this platform.
Early on, I could forgive because FW was one of the first users of the chip (for the first gen AMD laptop) and the driver support was clearly a bit bleeding edge. But we’re several years in at this point so I’m not sure what the deal is.
Most if not all of the hibernate issues are not specific to fw and to be fair they have reduced massively now, kinda sucks that they sometimes re-appear though, each kernel update is a bit of a dice roll now XD.
Specifically hibernate seems very fragile. Almost always kernel regressions too.
Yeah I would hesitate to blame FW. The main cause is probably AMD not prioritising Linux GPU driver development and they lack developer resources to catch everything.
Mine is working currently but honestly I’ve been riding the kernel updates. I haven’t made any changes and suspend-then-hibernate started working one day. It’s been okay for a couple of weeks now. I just upgraded to Fedora 42 and it’s still behaving.
Edit: I ran a dnf update and disabled a service I had to turn off bluetooth before sleep and suddenly things are working again. 2 successful hibernations.
Revisiting this, the problem has returned and has been plaguing me for about 2 weeks.
The regressions aren’t always in the GPU driver. There have been a number of “core” regressions as well that break hibernate for everyone (including non - AMD).
Hibernate is actively tested, but:
- Patches backport to stable kernel without dependencies sometimes causing breakage.
- When problems are found they take time to develop fixes.
FW13 AMD - Fedora 43 - Kernel 6.17.12-300.fc43.x86_64
Resolved hibernation issues by adding amdgpu.ip_block_mask=0xfffff7ff within GRUB_CMDLINE_LINUX=”” at /etc/default/grub then rebuilding grub via grub2-mkconfig -o /boot/grub2/grub.cfg and finally rebooting.
Possibly related to: [PATCH] drm/amdgpu: Fix query for VPE block_type and ip_count
AI Summary:
Description:
Manual hibernation (S4) and resume appear to “work” initially, but the amdgpu driver fails to correctly re-initialize the Video Processing Engine (VPE) upon resume. This leaves the GPU in a corrupted state that causes a hard system hang during any subsequent power transition (such as automatic idle-triggered Suspend or Hibernate).
Observed Symptoms:
- Immediately after resume from S4, dmesg reports a VPE ring timeout:
amdgpu 0000:c1:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] ERROR IB test failed on vpe (-110)
amdgpu: VPE queue reset failed - Following this error, the system remains usable momentarily, but the driver begins failing buffer allocations:
MESA: error: amdgpu: Failed to allocate a buffer - When the system attempts an automatic transition (e.g., KDE’s inactivity-triggered suspend-then-hibernate), the kernel encounters a “Wakeup event detected” or a driver hang. The Wayland compositor (KWin) stalls in an infinite loop attempting to restore output layers, resulting in a black screen and a totally unresponsive system requiring a hard power cycle.
The Workaround:
Stability is fully restored by disabling the VPE IP block via kernel parameters:
amdgpu.ip_block_mask=0xfffff7ff (Disables IP block 11).
With this mask, hibernation, resume, and automatic suspend-then-hibernate work perfectly.
Relevant Context:
I noted a recent patch submitted on Dec 22, 2025 by Alan Liu (AMD) titled “Query for VPE block_type and ip_count is missing.” The patch adds missing VPE cases to amdgpu_kms.c.
It is highly likely that the current kernel’s inability to correctly query the VPE block type and instance count results in the power management subsystem failing to properly initialize/restore the VPE 6.1 engine during the resume path, leading to the ring timeout and subsequent driver instability.
1 Like
I don’t agree with the possible patch.
This should be the right one
It was CC to stable but didn’t get picked up for some reason in 6.17.y afaict.
Try adding that.