Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: netnomad on November 12, 2013, 02:30:51 AM
-
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.
-
What about
cat /sys/power/state
-
hi tinypoodle,
that's what i get:
tc@box:~$ cat /sys/power/state
mem disk
-
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.
-
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.
-
You need to be root to echo to /sys.
Easy to try if anything changes while Xorg is not running ;)
-
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.
-
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.
-
"leave xorg" is ambiguous, do you mean you just switched to a VT or you killed the Xorg PID?
-
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.
-
"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.
-
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
-
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.
-
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
-
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.
-
Here is what I found on my machine, core 5.x with Xvesa, core 4.x console mode, dCore with 3.8.10, 3.0.21, and a custom 3.8.13 all will not come out of suspend to mem. Wheezy with gnome will come out of suspend, but a minute later the keyboard locked up and the screen had distorted display and then went black.
Not sure what the issue is, and after quite a few hard poweroffs I conclude that on my box suspend is just not a good idea.
-
hi jason w, hi tinypoodle,
i can confirm that microcore 5.0.2 has the same buggy behavior, so probably it's a kernel problem.
i used the same configuration, the same mydata.tgz.bfe, the same loaded extensions, the same bootcodes,
only core.gz, modules.gz, rootfs.gz and vmlinuz are taken from 5.0.2 and the resume from ram fails.
with core.gz and vmlinuz from 4.7.7 everything wakes up flawless after suspend to ram.
thank you for all your contributions.
-
Sounds pretty much like a potential regression in kernel.
Not sure what your chances are when reporting a bug upstream when it is a distro kernel, if you could reproduce with a kernel you build yourself might be an advantage.
Either way, you could search lkml.org and bugzilla.kernel.org and look for any related occurences reported.
I did a test myself with a clean 5.0.2 (norestore base) and "echo mem > /sys/power/state".
Result: No screen backlight but a howling fan upon resume, unresponsive to SysRq (which means really messed up, as at times SysRq would even still work after a kernel panic) - but then STR has never really worked on this machine in the past either, so that is different.
-
hi friends,
suspend-to-ram is an important feature for my daily life....
to provide a desktop that is instantly usable all day long without wasting too much energy!
i think that is the last main disadvantage of my dCore-5.14.04.01-configuration,
compared to that of microcore-4.77.
in the last posts some mentioned that the origin of this problem is caused by the kernel.
it would be really great to goal the suspend-to-ram-ability again.
thank you for all your hints and help.