You are not logged in.
If I choose suspend from a logout menu or suspend from XFCE power manager app, when the laptop is woken up the display is fritzed. It has white horizontal black and white stripes about ½ cm. I have to do a ctl-alt-sysReq REISUB.
But when I close the lid on batter power which is set to suspend, it comes back to normal. Just a lock screen and can continue. It does not matter if things are left up running or not. Perhaps GUI-suspend and close lid-suspend are not the same?
I have not used another power manager GUI.
Last edited by trilobite (2024-08-06 20:15:59)
{Linux-using people I haven't met are friends yet to be made.}
Offline
All the "gui" exit dialogue (bl-exit) does behind the scenes on the default setup is issue the command:
systemctl suspend
I'm not sure what XFCE power manager does, it may make a different system call, I'd have to dig into the source code to find out, or if it does something different on the lid close action compared to the app.
It could be that one is triggering s2idle & the other S3.
What's the output of:
cat /sys/power/mem_sleep
Also of:
cat /sys/power/state
Last edited by Bearded_Blunder (2024-07-24 04:54:06)
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
Here's the output. Does it make sense? Thanks!
$ cat /sys/power/mem_sleep
s2idle [deep]
$ cat /sys/power/state
freeze mem disk
{Linux-using people I haven't met are friends yet to be made.}
Offline
It makes sort of sense, does indeed look like one is using S3 & the other something else.
Now I've to figure out a non destructive low-risk way to test a potential cure. hmmm...
Open a terminal & enter this:
echo s2idle | sudo tee /sys/power/state
Then report back if that cures the suspend button in bl-exit, or if it messes closing the lid up.
If it messes both up a simple reboot should revert things to how they are now, & i'll have a clue what needs changing in systemd's sleep settings to make your system behave. in either case.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
It responds with
$ echo s2idle | sudo tee /sys/power/state
s2idle
tee: /sys/power/state: Invalid argument
{Linux-using people I haven't met are friends yet to be made.}
Offline
That'll be beacuse I said the wrong one, sorry tired....
echo s2idle | sudo tee /sys/power/mem_sleep
The idea being it then puts the [brackets] round that one for testing, you can check first by
cat /sys/power/mem_sleep
Again...
Then test, sorry.
Doesn't help that the systemd documentation is, as usual, impenetrable...
Scratch that, I'm still going about this wrong....
Want to test directly, not indirectly, find which state gets recovered from correctly, then we alter the config to call that one instead of trying 3 in order... (one of which your system doesn't advertise supporting).
Sorry to mess you about...
Reboot just to reset everything to the normal state, nothing written by us, & then try each of the following, tell me which it recovers from properly...
echo mem | sudo tee /sys/power/state
then
echo freeze | sudo tee /sys/power/state
Once we know which your system does right, we can configure systemd to only try that instead of trying mem standby & freeze in that order...
There is a logic behind this I'm just losing the plot...
Last edited by Bearded_Blunder (2024-07-24 23:41:13)
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
echo mem | sudo tee /sys/power/state
works normally. This is good.
echo freeze | sudo tee /sys/power/state
does badly. It did a black screen, though that may be related to what is displayed when it invoked? I had nothing up but a terminal versus firefox and some other things I often have open. This is versus the white stripe thing.
Last edited by trilobite (2024-07-26 23:08:31)
{Linux-using people I haven't met are friends yet to be made.}
Offline
Ok, I expected the other way round. Judging from the documentation, but then we are talking about systemd...
It's "supposed to" try mem first, according to the manpage & example config, however, with luck, this should fix it:
First make a directory for our config change to get read from
sudo mkdir /etc/systemd/systemd.sleep.conf.d
Then create a config file
sudo nano /etc/systemd/sleep.conf.d/SuspendState.conf
and put the following in it:
[Sleep]
SuspendState=mem
Save & exit.
That should in theory cure it by making it basically write mem to /sys/power/state to sleep, though you might need to reboot or restart the systemd sleep service before the change takes effect (probably).
If it all EFFs up, just delete that new file, the directory can stay. We just probably need to set a different key in that case. We don't want to have it writing disk there, that'd cause it to try to hibernate. The system I'm trying out on offers "standby" in addition to "freeze" or "mem" in /sys/power/state, which setting this way cured mine from not waking up. So you've done me a favour by making me bother to fix mine.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
Thanks. Delay due to holiday with demanding family.
The file I saved to is
/etc/systemd/systemd.sleep.conf.d/SuspendState.conf
because sleep-conf.d did not exist.
This works. I'll see how it performs with a few things open, but results on a user evaluation basis: faster to come back to life, uncertain if faster to go to sleep. But results are very fine indeed.
Thanks so much for your help and solution.
Last edited by trilobite (2024-08-04 20:52:16)
{Linux-using people I haven't met are friends yet to be made.}
Offline
The directory doesn't exist on a standard Debian/Bunsen install, but the documentation suggests creating it & placing modifications there is preferred over editing /etc/systemd/sleep.conf directly in the same way adding repos is preferred to be done by putting files in /etc/apt/sources.list.d/ rather than editing etc/apt/sources.list
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
Interesting. There was nothing inside my "/etc/systemd/systemd.sleep.conf.d/SuspendState.conf" at all.
Thanks for the updated info about this too.
Last edited by trilobite (2024-08-04 22:43:11)
{Linux-using people I haven't met are friends yet to be made.}
Offline
There wouldn't be, it's a new file you created.
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline