Suspending laptop freezes the entire system

Hello. I really hope this is the correct sub-forum for this problem.

So I have an Acer laptop model A315 from this year, using XFCE desktop. This is a just clean Leap 15.4 installation, so by default closing the lid is configured to suspend, not hibernate.

I think I have a very bad problem with the suspension function: when I suspend --either with the suspend button (NOT hybrid suspend) or closing the lid-- and try to wake it up, system is frozen and completely unresponsive, and I have to force shutdown by holding the power button, which is bad.

A brief background just in case: before this, I once tried draining the battery to 4%, and instead of automatically hibernating, it popped a window asking for root permissions to run the hibernation. But I just hit cancel and plugged the laptop to AC.

Could someone help with this?
Thanks very much.

I was scolded by a mod by PM regarding the threads I make a couple of days ago, and even when I put effort this time with this one, the result is the same: ignored. Great.

Well, nobody can press people to answer on threads when they do not want, or do want but have no time.

I have the impression that the majority of people do not use XFCE, so the pool of people that can help you maybe a bit smaller then usual.

Personally I can not help. I do not know much about hardware, nor about what could go wrong with suspend while using XFCE (as KDE user).

When this gives you comfort, I think the question as you have put it here is clear enough and provides at least enough information to start from. So it is definitely not your post as such that makes you feel you are ignored. I doubt very much you are ignored

I really can’t help either.

I almost never suspend. And that’s because I see the idea as an ugly hack. I’m actually not surprised that it doesn’t work properly on some hardware.

I am not a laptop user, but I do have one here (Leap 15.4 and using KDE). When I close the lid it “stops working” (I do not know what the correct technical word is: sleep, suspend, …?). When I then open the lid and then press the power button, it starts “buzzing” and I have to enter the user password like when screen locking. The session comes back. That is all I can say about this.

Hi
I use neither even on laptops… I would suggest checking systemd options at /etc/systemd/logind.conf as it could be one of the lid options overriding your expectation on the xfce desktop. If possible remote in via ssh and tail the journal journalctl -f to see what is happening when you close the lid.

People will answer when they feel that they can add some value.

Have you use it on other DE before? Like KDE or Gnome? Did it work before?
Is “upower” is installed?

Just tested with other DEs such as KDE and GNOME. Exact same results.
Package upower is installed. FWIW, its GPU reads “Intel iRIS Xe” in the label.

More likely a BIOS issue, not an openSUSE issue as such.

Just two of many reports I turned up during a quick search…

https://community.acer.com/en/discussion/665697/aspire-a515-56-bios-update-to-1-26-troubles-suspend-functionality-on-linux-fedora-35

https://forum.endeavouros.com/t/suspend-hibernation-non-functional-on-acer-aspire-3-laptop/22972

I have the same problem on a Dell Inspiron 15 3525 laptop. After many kernel upgrades and two BIOS updates. the problem still persists. This problem is also well known on Dell’s website, with all versions of linux. What I’ve found so far is that after forcing a power off and rebooting, the command:


journalctl -b -1 | tail

shows that the system successfully entered s2idle sleep, but was unable to wake up. This command shows that the kernel thinks this laptop supports s2idle sleep:


> cat /sys/power/mem_sleep 
[s2idle]

However, this Windows 11 command says otherwise:


powercfg /A

tells me that my hardware only supports Standby (S0 Low Power Idle), and specifically that s2idle is not supported. So, after every kernel or BIOS update, I check /sys/power/mem_sleep and Windows 11 command, powercfg /A, to see if anything has changed.

I hope this sheds some light on new hardware and linux sleep failing to wake up.

Gene

EDIT: Just an FYI, I’m currently running the latest master branch kernel:


6.0.0-rc7-2.g70d9c50-default

and sleep is still broken.

Gene

I forgot to mention that all you can do to avoid lockups is to disable sleep. You can muck with the button settings in the file /etc/systemd/logind.conf, or just disable suspend and sleep completely with the command:


sudo systemctl mask suspend.target sleep.target

If you want to re-enable them for testing, use the command:


sudo systemctl unmask suspend.target sleep.target

Gene

It works on most hardware. I never power off host erlangen. According to journal I suspended and resumed the system 56 times since Sep 20. Power consumption during suspend to RAM is 2W measured at the power cord.

**erlangen:~ #** journalctl -b -u systemd-suspend.service --output short-monotonic  
 3604.109498] erlangen systemd[1]: Starting System Suspend... 
 3604.120865] erlangen systemd-sleep[7143]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend 
 3604.121316] erlangen systemd-sleep[7141]: Entering sleep state 'suspend'... 
 3607.166954] erlangen systemd-sleep[7210]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend 
 3607.169883] erlangen systemd-sleep[7141]: System returned from sleep state. 
 3607.171371] erlangen systemd[1]: systemd-suspend.service: Deactivated successfully. 
 3607.171411] erlangen systemd[1]: Finished System Suspend. 
**erlangen:~ #**

systemd-suspend cycle is three seconds. This is fast compared to startup from power off:

[FONT=monospace]**erlangen:~ #** systemd-analyze 
Startup finished in 44.927s (firmware) + 3.651s (loader) + 3.115s (kernel) + 2.195s (initrd) + 2.472s (userspace) = 56.362s  
graphical.target reached after 2.472s in userspace.
**erlangen:~ #**[/FONT]

openSUSE systems are more susceptible to malfunction compared to Fedora, Arch, Manjaro and others: https://forums.opensuse.org/showthread.php/549364-AMDGPU-driver?p=2998696#post2998696, https://bugzilla.opensuse.org/show_bug.cgi?id=1177428. Problem was fixed by switching from the Gigabyte B450 Aorus Elite to a ASUSTeK PRIME B450-PLUS mainboard.