Recently bought a new laptop that comes with an AMD Radeon gpu and installed OpenSuse Tumbleweed on it which I had installed on my previous laptop as well but never had issues with suspending and resuming. However, with the new laptop, I am unable to resume after suspending or closing the lid unless I force it to shut down by holding the power button which is a major inconvenience.
Any suggestions or advice would be greatly appreciated.
If you can’t get the laptop to resume when the OS isn’t even active anymore, either the power management is broken (s0idle issues most likely, possibly after transitioning into another idle state) or the firmware is broken. In some rare cases, the problem is with the ACPI table embedded in the firmware, but you could treat that like a firmware issue because you don’t have any control over it. Either way, your ability to debug this is rather limited, as most hardware is disabled the moment you suspend your laptop.
You should check if there are updates for your laptop’s motherboard firmware. You’ll have the best chance at this using Windows, because many manufacturers don’t release all that many Linux compatible updates. Previously, AMD has had to release firmware updates for some of their CPUs, as well as kernel patches. Also check for firmware updates for other components (SSD/TPM/what have you) because they could all play a role in the suspend process.
I don’t know OpenSuse well, but generally attempts to fix this on the Linux side include trying older kernel versions (as Tumbleweed is a rolling release distro). If an older version does work, you should file a regression report so someone can fix it in the current kernel.
I was able to figure out that it does not suspend at all when I close the lid or click the suspend button on Gnome. Only found this out because when going through YaST Services Manager and manually starting systemctl suspend, the laptop suspends just fine and wakes back up. So I’m starting to think it’s more of a systemd issue? Any inputs?
I doubt it, Gnome just runs the standard dbus suspend call as far as I know (source).
However, there are different ways to suspend the system (configured by echoing a magic word to a file in /sys) so it’s possible the GUI is somehow misconfiguting the system based on what the OS reports to be the preferred suspend method. From browsing the source code, it seems like Gnome will do a Dbus call which systemd receives, and after receiving that it seems to start the suspend service? It’s a bit hard to follow with all the dbus interaction.
This seems to be where sleep is actually requested, This is where the requested command is mapped to a specific action that is then started by the systemd manager, which is defined as a string here.
As far as I can tell, clicking suspend is the same as running
systemctl start suspend.target. But maybe there’s more going on, perhaps something else is intercepting the dbus call to suspend, preventing systemd from doing its job?