suspend-to-ram (STR) in dCore-5.13.11.06

[netnomad]

hi friends,

did you succeed with suspend-to-ram?
after the resume i get a black screen and the system seems to be frozen:
no effect for key strokes like shift, num-lock.
this behavior or problem is often reported in the web community, especially with my i915-intel-card

one major problem seems to be that for /sys/power/state even root has no permission and some commands think that it doesn't exist (the file is there but with the editor of midnight-commander strange characters are in line2).

i tried pm-utils, uswswap and acpid with s2ram with different options...
and added the boot-code acpi_sleep=s3_bios.

do you think that the kernel has all needed options or do i need more modules loaded?
i know that it's a common problem, but i'm curious whether you succeeded.

thank you for your replies.

[tinypoodle]

What about

Code: [Select]

cat /sys/power/state

[netnomad]

hi tinypoodle,

that's what i get:

tc@box:~$ cat /sys/power/state
mem disk

[tinypoodle]

This means basically your system has capabilities to suspend to RAM and/or disk; my guess is that it might not be the best idea then to use mc to peek at /sys files.
Generally speaking, behaviour of suspend depends to a big degree on hardware and BIOS; and probabilities of success are higher with STD compared to STR.

[netnomad]

This means basically your system has capabilities to suspend to RAM and/or disk; my guess is that it might not be the best idea then to use mc to peek at /sys files.

yes, you're right that mc is not the best tool.
usually
tc@box:~$ echo mem >/sys/power/state
bash: /sys/power/state: Permission denied
should work.
 

Generally speaking, behaviour of suspend depends to a big degree on hardware and BIOS; and probabilities of success are higher with STD compared to STR.

with microcore 4.7.7 and xvesa i have no problem at all to suspend-to-ram.
i'm not sure whether xorg or the newer kernel causes this problem.

[tinypoodle]

You need to be root to echo to /sys.
Easy to try if anything changes while Xorg is not running

[Jason W]

netnomad -

Does this also happen in regular Core 5.x, with the 3.8.10 kernel?

That would help narrow it down to kernel, which on searching google it appears to be kernel related for those cases.

[netnomad]

hi tinypoodle,

after
tc@box:~$ sudo su
root@box:/home/tc# echo mem > /sys/power/state
the system falls immediately into sleep... it seems that there is no time to save the state.
when i try to wake up the system, only a white cursor in the left upper corner is blinking and no key stroke seems to give any feedback.
the system shows the same behavior, if i leave xorg and use the commands on the command line without xorg.
the main button is the only way to reboot the system, no ctrl-alt-delete or alt+print+RIESUB show any reaction

hi jason w,
sorry, but i didn't try the regular core 5.x with the 3.8.10 kernel yet.

thank you for your help.

[tinypoodle]

"leave xorg" is ambiguous, do you mean you just switched to a VT or you killed the Xorg PID?

[Jason W]

I just now seen the same behavior in TC 5.x suspend to disk with Xvesa as well as dCore with a newer kernel suspend to RAM. Maybe the newer kernel, maybe not at this point.

[netnomad]

"leave xorg" is ambiguous, do you mean you just switched to a VT or you killed the Xorg PID?

hi tinypoodle,

i did "Exit to prompt" with "TC Exit options", so i probably killed xorg pid.

[netnomad]

I just now seen the same behavior in TC 5.x suspend to disk with Xvesa as well as dCore with a newer kernel suspend to RAM. Maybe the newer kernel, maybe not at this point.

hi jason w,

with 4.7.7 and some native debian-configurations i succeeded with a script like this:

#!/bin/sh

vt='/usr/bin/fgconsole'
sudo rmmod oss_ich
sudo rmmod oss_usb
sudo rmmod oss_hdaudio
sudo rmmod osscore
sudo s2ram --force --vbe_save
/usr/bin/chvt $vt
sleep 1
sudo modprobe osscore
sudo modprobe oss_hdaudio
sudo modprobe oss_usb
sudo modprobe oss_ich

the black-display-problem could be prevented with the change of the virtual terminal...
... the other lines are just for the sound modules

[tinypoodle]

Eh, not exactly same subtlety of methods...
Please try with s2ram with same parameters then, and stop OSS4 first, IIRC with Core you should first execute the script to stop OSS4 rather than directly rmmod'ing the modules.
I suggest you try manually issuing one command after the other and not using scripting until you got it to work.

[netnomad]

hi tinypoodle,

i don´t use this script for testing in dCore,
i use it only in microcore 4.7.7 and it works properly on my and many different further hardware-environments.

in my testing with dCore i just try single commands in xterm (or after "Exit to prompt" with "TC Exit options") like

s2ram
s2ram -f
s2ram -f -p -m

but it´s always the same result

what do you think about this approach?
https://ubuntuforums.org/showthread.php?t=1978290

[tinypoodle]

I wouldn't know about that link, but if it works for you with 4.7.7 you should first try the exact same steps, and preferably test with regular Core 5.x as Jason W suggested in Reply #6 for a diagnostic conclusion.