Various bad things are happening now on this kernel after relative stability on 6.17.
Updated to the latest BIOS.. things are so unstable i’ve had to switch to hibernation.
I just noticed that I cannot suspend my FW13 nor does it lock the screen automatically if I walk away. Locking the screen leaves the screen active. Also if I power off the laptop, the external monitor never goes into standby mode after the latest updates. I haven’t yet run into issue with waking from suspend
(AMD Ryzen AI 300 Series) (A5)
Kernel: Linux 6.17.12-300.fc43.x86_64
Hey @Mario_Limonciello, sorry for tagging if you are on vacation or moved on etc.. been a while.
Two things on Fedora that could influence this.
A bad Linux firmware upgrade that Fedora didn’t pull up the revert.
A missing revert for a VPE issue. This is in later stable kernels but you would need to cross reference if it’s in Fedora yet.
I’m on arch though.
core/amd-ucode 20251125-2 (244.0 KiB 602.9 KiB)
Microcode update image for AMD CPUs
just noticed I havent got the amd-ucode package installed.
Oh I skimmed the thread and saw Fedora mentions. You should check if you picked up same reverts in arch too.
I think I’ve resolved my issues which were twofold.
Downgraded to 6.17.9, lets see if these problems get solved in the new year.
hmm.. finding the restart-on-resume behavior with 6.17.9 too
And various other older kernels.. so kinda stumped, firmware problem? By far the biggest issue is the laptop doesnt wake when lid is opened, and pressing the power button results in a restarts.. particularly frustrating.
I’m running NixOS on the AMD Ryzen™ 7040 Series Framework 13. I had this issue last week where the computer wouldn’t wake up from suspend mode and one time was overheating. I found that updating the bios to 3.17 fixed the issue for me.
I’m on 3.17.
I’ve downgraded these packages to see if there’s improvement:
core/linux-firmware 20251125-2 (2.4 KiB 0.0 B) (Installed: 20250627-1)
core/linux-firmware-amdgpu 20251125-2 (25.3 MiB 26.0 MiB) (Installed: 20250627-1)
Early signs are good bet lets see over the next few days.
I don’t know if it helps at all.
I have a FW16 AMD 7840HS, and 6.18.2 kernel from mainline. I have not had suspend / resume problems.
If the resume problems on the FW13 are power related, I would suggest trying to resume from suspend without the PSU plugged in, and then plug the PSU in while it is working.
It would be interesting to know if the problem is PSU related.
➜ ~ uptime
13:57:13 up 23:16, 1 user, load average: 1.47, 1.48, 1.70
working great so far.
Completely different issues on Deb14 (testing/unstable mix) on 6.17.12: The battery was on 55% and suddenly at 0%.
I’m still not entirely satisfied with the time that an 80% battery gives me. I’m shutting it down currently as it will be empty within a day or two when the lid is closed.
I’m going to upgrade to the unstable kernel, 6.17.13, see if that changes things. I’ll check back here.
I was having some issues with suspend using that specific kernel version (6.18.2) on arch, but not as described, my issues was basically when connecting to a usb4 dock after waking up from suspend the dock didn’t do anything other than charge my laptop or completely lock the pc until I either unplugged the dock or rebooted in some cases, I tried to add “nvme.noacpi=1” to my kernel cmdline as per an AI suggestion, and ofc it broke the suspend on my AMD system because I didn’t bother to come to the forums and see that that option breaks suspend on AMD systems, nevertheless I just was dealing with is by rebooting my PC before plugging it into the dock for the past week, basically on that kernel the thunderbolt tunnels were never coming back from a suspend state from what I could tell, or would just straight up assume that the dock was connected when it wasn’t, probably because I usually just unplug the dock and close the lid.
However after updating the system and my bios to the most recent versions (kernel 6.18.3 and bios 3.17) the issues I was having with suspend completely breaking the thunderbolt tunnels were gone, if I recall correctly at the time I was running this older kernel I did have one straight up scenario where the laptop wouldn’t boot from suspend and the acpi.nvme flag wasn’t present, at the time I thought it was just the tunneling conflicts breaking something, and I since USB4 hubs pollute logs when outputing to displays on AMD systems I didn’t bother to actually check the logs, eventually I was able to solve most of my USB4 issues by simply adding more bandwidth via the cmdline.
All this to say that the 6.18.2 kernel wasn’t really as stable (specially with suspends and while operating in power saving mode) as 6.18.3 on my system, but it could also be caused by me running the 3.09 bios at the time