Yes, I’ve seen many reports in this forum about suspend not working. I have read many of them and haven’t found any answers yet which is why I posted here. What’s unique about my case (as far as I can tell) is that it was working fine until I upgraded to F41. So, something changed in F41 that broke it. I’m not sufficient well-versed in Linux to know where to start looking.
The code that handles device power management is “close” to the hardware. (There are “layers” of code that run on the hardware, starting with the firmware, then the kernel, then various user-space programs.) It is likely that the problematic code is in the kernel (though the real problem might be in the firmware or even hard-wired into the hardware).
It should be pretty easy to revert to using your previous kernel package and see if that works around the problem you are seeing. In fact, your previous kernel might still be installed if you upgraded recently. Can you get your bootloader menu to show by holding the SHIFT key while booting your system and, if so, do you still have a Fedora Linux 40 kernel available to boot from?
It’s a dual-boot Windows/Fedora system and the sleep function in Windows still works fine, so I’m confident it’s not a firmware or hardware issue.
Further data points: after the system goes into the state I described above, I can no longer ssh into it or ping it. And the journal for sleepd says that it successfully entered the sleep state. So it’s clearly going into something like a sleep state. But as I say, the power light stays on, the fans keep running and I can’t wake it.
Anyway, thanks for the suggestions. I’ll see if I can revert to an earlier kernel.
Just because one piece of software can interact successfully with another piece of software does not negate the possibility that one, the other, or both are deviating from the specification.
If you do not still have an older Fedora Linux 40 kernel installed, you should be able to install one with a command along the lines of dnf downgrade --repo=fedora --releasever=40 kernel*.
Exactly the same issue, it’s not your hardware, Fedora broke something from 40-41 and it is still broken! I can’t believe this persisted after 41 final came out, I thought originally that it was some beta bug. Some people in other threads think it’s a Nvidia driver issue but I’m all AMD. It also doesn’t have anything to do with Gnome because I tried the KDE version and had the same issue.
After upgrading to Fedora 41 I had been experiencing the exact same thing described by OP. However after some additional updates / kernel upgrades and also updating my notebook’s UEFI firmware the issue I’m facing is now different: it will suspend just fine but only on the FIRST TIME I try it on the same “boot”. After resuming, subsequent attempts to suspend the system will always fail.
In this state, the system becomes partially unresponsive. I can still move the mouse around, but interacting with some parts of GNOME’s UI won’t do anything and I can’t open most of my apps. If I try to lock the screen, I’m unable to log back in since the password field doesn’t register anything I try to type on it. After a while, the system will crash.
The affected machine has an AMD Ryzen 5700U with integrated graphics (Acer Inspiron 5).