-   Linux - Hardware (
-   -   How does hibernate affect my suspend/resume ? (

maeschbach 07-17-2010 01:57 PM

How does hibernate affect my suspend/resume ?
3 Attachment(s)
My system is able to resume from suspend only after I've let it hibernate:scratch:.

When I do a fresh boot and suspend the system just after the desktop started, resuming will result in a black screen and I had to power off the computer (see pm-suspend-kde-fail.log).

When I do a fresh boot, hibernate the system just after the desktop started, resume, and do the suspend then, the system resumes without a problem (see pm-suspend-kde-success.log).

Does somebody know what could be done by hibernate that is needed for a successful resume after suspend but is not done by suspend alone? How does hibernate affect my system?

Resume from suspend fails also when I load just the kernel with

as kernel parameter, mount the sysfs with

mount -v sysfs /sys -n -t sysfs
, and send the computer to sleep with

echo -n mem > /sys/power/state
. (Slackware 13.1 generic-smp:, custom built, and custom built 2.6.35-rc5). Disabling KMS with kernel parameter


does not help, too.

I had absolutely no problem with Debian Lenny but now my root partition has an ext4 file system which is not supported by the kernel.

Thanks for your help.


rjcooks 07-17-2010 02:34 PM

I'm guessing this is a laptop(Intel Corporation Mobile ...). Dell by any chance?
Is the (KDE) plasma-powerdevil ap installed? If so, try removing it as solution( Latest version seems to have issues ... esp. with Dell mobiles. ).
If not a power management ap interfering I'm not sure what other than possibly some Slack code or perhaps size of the swap.
The swap, IIRC, needs to be larger than the size of / and it needs to be specified during kernel compile for suspend/hibernate to work properly. I see there are some custom kernels -did you specify the swap location? if not try that.

Otherwise, I am out of suggestions. ...

maeschbach 07-18-2010 03:35 AM

rjcooks, it's a Lenovo S10. Please note that hibernate works perfectly. I made the swap partition a bit larger then the amount of RAM in my system. To make it twice as large as my root partition would be a bit exaggerated;). I did not specify the swap partition during compilation but append it with

as kernel parameter. The KDE does not seem to be involved because I encounter the same problem when I boot in the console only. - and I had this problem not with Slackware only but also with Ubuntu 10.04, MeeGo 1.0 and PeppermintOS One.
What I would like to understand is why I do need to hibernate my computer in order that it resumes correctly from suspend to RAM.

rjcooks 07-18-2010 04:10 PM


Originally Posted by maeschbach (Post 4036910)
What I would like to understand is why I do need to hibernate my computer in order that it resumes correctly from suspend to RAM.

In the Linux (2.6.*) kernel, hibernate is suspend-to-disk, suspend-to-ram, suspend-to-file and ALL are implemented by swsusp.

Swsusp is very limited compared to proposed successors. My only WAG here is that the system configuration is such that the RAM *must* be copied to hard disk(like in hibernate) so until it is done, the resume from "sleep"(suspend-to-ram) will not work. ...

Take a look at TuxOnIce as it may|should serve your needs better. It is the proposed replacement for swsusp.

There are only two things, other than swsusp and previously mentioned interferences, that i know can be causing the issue where the "hibernate" is needed before "sleep" can be done & resumed properly.
One is the init and the other is the system BIOS.
The init being used is supposed to be the one you created with make initrd after creating the custom kernels. You can make another if that init is not doing the job. As mentioned, it could be because the location for the "resume" was not specified ...
The BIOS of a computer, especially a laptop, can dictate what can or cannot be done. Before going too crazy, make sure the BIOS is setup to allow sleep(only suspend to ram) because some|many laptops do not do that -they suspend(hibernate).

I hope this bump to the top of the list gets you more help. I do not use these functions because in my experience, they are useless since turning off the system does better and starting the system takes almost the same amount of time. IOW, sorry if it does not help but I cannot do any more.

Good Luck ...

maeschbach 07-19-2010 02:20 AM

rjcooks, thank you very much for all that information. The BIOS should be fine since at least with a not so recent version like Debian Lenny, everything is fine. What I think is so funny about the resume partition is that I don't even know if it was configured correctly on Lenny because I never used hibernate - why should I, since suspend to RAM worked flawlessly and, as you wrote, resume from hibernate is not faster then a fresh boot. I'm ready to believe that a bit of information (perhaps some addresses) *must* be stored to disk in order to let the system resume correctly and perhaps it's only hibernate that does this job well. Do you know if the pm-utils call swsups, too ? It's perhaps time to open the source packages ;).

rjcooks 07-19-2010 01:20 PM


Do you know if the pm-utils call swsups, too ?
Do not know. Like I said don't use so not that knowledgeable about it.
I've read enough to know I would use TuxOnIce if I did use it. I run 24/7 usually and shut off monitor(not blank, but "off") when not active for 30 minutes. Shutting off HDD, resume, off, resume, ...blah is, next to bouncing them off the floor, the worst thing one can do to HDD. The cold-hot cycles are terrible for them. FTM, almost all electronics are that way.( The materials are only capable of handling so many cycles before stress failure occurs. )

I've been thinking about using hibernate during sleeping hours or long absences but it is only on the list. I won't know any more about the internals until I try it again ... which might be a very long time, ;).

maeschbach 07-19-2010 01:48 PM

Will think about it ;).

maeschbach 09-08-2010 02:30 AM

Today is a lucky day for me! Suspend to RAM works now; at least the last several times I've tried (with kernel boot parameter acpi_sleep=s3_bios, booting Fedora 13 with kernel

All times are GMT -5. The time now is 08:31 AM.