Which kernel are you using? 6.17.6-300.fc43.x86_64
Which BIOS version are you using? 03.04
Which Framework Laptop 13 model are you using? AMD Ryzen AI 9 HX 370
Hi all–I recently upgraded the mainboard in my Framework 13 (from the 7040) and, since upgrading, the laptop fails to resume from hibernate very frequently, I would say more than half the time.
Initially I did not reinstall the OS and just did the upgrade in place and everything else seemed to work seamlessly. I had hibernate working well prior to the upgrade with a swap subvolume (set up using this guide https://fedoramagazine.org/update-on-hibernation-in-fedora-workstation/). After the mainboard swap, however, upon resuming there would be an extended period where the screen went dark after the bootloader (maybe 15-30 seconds) and then displayed the following corrupted image:
I was concerned that not doing a full OS reinstall might be the issue, so I have since reinstalled fedora 43 KDE twice and set up hibernate (first to swap partition, then again to swap subvolume) but the issue seems to be unchanged. I do not think there is any issue with the hibernate setup per se (the volume/parition are generously sized at 64 gb vs 32 gb RAM and it worked with the previous mainboard). I checked journalctl to see if any errors were being thrown during resume and as best I can tell there is an issue with amdgpu. I’m not sure what part of the output would be most useful, but here is partial output with ‘grep amdgpu’ for now. Can provide more as requested:
I did some googling for similar issues but didnt find much–the most I found was a suggestion to add some kernel parameters that may correct issues with gpu power state changes (I think?) such as ‘amdgpu.runpm=0’ or ‘amdgpu.dcdebugmask=0x10’ but these did not make a difference.
Thank you in advance if anyone has any suggestions!
EDIT: I don’t think the journalctl output I had above was terribly useful, so I snipped it out for now, the full output from a failed resume ‘journalctl -b -1’ can be found here: Dropbox
I see the exact same behavior on my Framework 13 Ryzen AI 7 350 using Fedora 43 / BIOS 3.04 / Kernel 6.17.7-300.fc43.x86_64. Would appreciate if any insights can be shared here.
I just recently heard back from the support team, just haven’t had a moment to go through their recommended troubleshooting yet. Will definitely report back if I learn anything.
Appreciate your sharing your experience–makes me feel a bit better knowing that I’m not the only one with this issue, was concerned it may be a hardware fault.
I submitted the requested log files to framework support, so we’ll see what they have to say.
In the mean time, I was playing around with adding some amdgpu related kernel parameters to grub that I found though some searching around. A post on this thread
suggested adding the parameter “amdgpu.dcdebugmask=0x12”
I just appended that to GRUB_CMDLINE_LINUX in /etc/default/grub and regenerated the config file. I tried hibernate/resume afterward and it actually worked! I won’t celebrate quite yet because the symptoms were already somewhat erratic and this seems to be a temporary workaround, but I might be getting somewhere.
Quick update–just tried it again this morning and it’s back to the original behavior, corrupted graphics and all. Seems like that last one was a fluke.
Just posting a follow up after some back and forth with support. I’ve tried a few suggestions with no avail, so the current plan is pretty much to avoid using hibernate/suspend to disk until this behavior is fixed in the kernel/amdgpu driver. This response from support sums it up:
“hibernate to disk on on these AMD configurations is spotty at best. For example, I still use hibernate on 7040 Series, but on AI 300, it has become something of a known bug. All we can do is throw parameter at it and wait for the bug to be patched.”
I’ll periodically test it out as Fedora pushes out updates (or I try a more bleeding-edge distro), but it seems like we’ll be in a holding pattern until then. I appreciate Framework’s support team’s attention to this.
hibernate on the 7040u series has been pretty rough too, especially initially. It got better over time but never really got as reliable as it was on my previous laptops (then again this is the first time in a very long time I got new hardware so my previous ones had a lot more time in the oven before I got them so that may be normal).
Yeah, I had the same experience. It was working pretty consistently lately with the prior mainboard (a 7840u), but there would still be an errant failure to resume once in a while. I’ve considered swapping the old mainboard back in for now, but I figured I would just wait it out. Plus it will be easier to test new kernels periodically if it doesn’t mean swapping mainboards again.
Most of my mobile computing lately has been on a thinkpad carbon x1 12 with arch—everything has been running smoothly on there, even hibernate/resume.
Shortly after my prior post (for unrelated reasons) I installed CachyOS on this machine. Initially with the 6.17 and early 6.18 kernels I was experiencing the same behavior. However as of the most recent kernel update last nite (6.18.2-3-cachyos) I can successfully hibernate and resume from a swap subvolume. Hopefully when fedora is on this kernel generation the issue will also be fixed on that distro
