Looks like it has something to do with the recent kernel.
I downgraded to 6.18.20-061820-generic and last several hiberation cycles were all fine.
The only issue I am experiencing right now is that sometimes kernel refuses to hibernate stating that there are no enough free pages. That’s strange since my swap partition is large enough to fit all the RAM and usually only ~40% of the RAM is occupied.
Update: Looks like the original issue was definitely caused by recent kernel. After I downgraded I was able to hibernate a dozen times or so and everything went OK. With the exception of failed attempts like this:
Most of the times vm cache flush with subsequent hibernate worked… until today.
Last time the hibernation attempt failed, but the kernel failed to recover from it with huge cascade failure in amdgpu. After it the laptop was running kinda OK (I heard notification sounds), but the screen was dead and I wasn’t able to reboot it gracefully.
That’s part of why I think an LLM might be able to shine. You can tell it to do this overnight and try 10 times at each commit. It can schedule a wake using wakeup timer.
Then it’s not hands on at all for you. Just set it and let it chug overnight, and if it’s not done by morning do it again the next night.
Hi @Mario_Limonciello, you may or may not remember me from the MES ring buffer full saga. I’ve been having GPT-6 diagnose sporadic hibernation failures on my machine, and it pointed me to this thread and suggested the following comment:
I’m seeing hibernation failures on a Radeon 890M, kernel 7.3-rc2, with 32 GB RAM, 48 GiB swap, zswap disabled. Snapshot creation fails with ENOMEM, then gfx_v11_0 recovery and pci_pm_thaw fail with -110. Fallback suspend hangs until the device watchdog panics. I have a pstore dump capturing that sequence.
Preallocation allocated 10.4 GiB for the snapshot, but after device freeze the snapshot required 18.7 GiB, with only 12.6 GiB available. One possible lead: amdgpu_pmops_prepare() appears to skip preparation for APU hibernation because both S3/S0ix predicates are false. GPU-memory evacuation then happens after snapshot preallocation. Could that explain the late memory growth? This is a source-
level hypothesis; I haven’t validated a fix yet.
Crash log attached, renamed .stl because the forums seem to not allow txt or zip XD
Haha, always love to find out a fix was devised right around the time I finally figured out the problem…
Astra does say this, though (feel free to ignore if slop):
Thanks—hopefully this fixes the issue. I am suspicious of a separate ordering issue, though: on this APU, both S3/S0ix predicates are false during hibernation, so amdgpu_pmops_prepare() skips preparation. GPU-memory evacuation then happens in the later freeze callback, after snapshot preallocation. TTM copies GPU buffers into shmem, while their old backing pages can remain resident in the unused TTM pool. That could increase the memory needing a snapshot after the kernel has already budgeted for it.
My dump shows preallocation completing at 10.4 GiB, then the final snapshot requiring 18.7 GiB with only 12.6 GiB available. So keeping kernel threads alive during preallocation may fix the reclaim deadlock, but still leave this late allocation problem.
Would calling just amdgpu_device_evict_resources() during APU S4 preparation—before snapshot preallocation, retaining the later eviction pass—be the appropriate fix? That would let reclaim account for the shmem copies and pooled pages without enabling unrelated IP preparation callbacks. I haven’t yet measured whether this path accounts for the full increase.