dCore Import Debian Packages to Mountable SCE extensions > dCore X86

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

<< < (4/4)

Jason W:
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.

netnomad:
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.

tinypoodle:
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.

netnomad:
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.

Navigation

[0] Message Index

[*] Previous page