ACPI Suspend/Resume your Linux
Wow. Isn't it cool that I'm still talking about this in 2007? When Windows/Mac folks have it working for years without bothering?
I think this is the most frequent problem happening in Linux, and for some reason you have to solve it over and over, usually involving different steps. It never works until it suddenly starts working and sometimes you don't even remember what you did. :-) Only SynCE is more complicated (I actually made that work, once, then upgraded the kernel and even though I patched and reinstalled all SynCE stuff, it's not working anymore. God only knows why. But that's a future story).
(Note that though this is a rant, my intention is not to criticize any developers. I know that they are doing a great job, given the limited information that hardware makers provide. I just wish this would be easier to configure properly...)
About 50.000 ways to do it
Well, not quite fifty thousand, but:
Suspend to RAM. What does this involve? You basically need an ACPI supporting kernel and hardware, then you should be able to do:
echo -n mem > /sys/power/state
That's it. But no. We have:
Suspend to Disk. Assuming supporting kernel and hardware, you need to do:
echo -n disk > /sys/power/state
But, we also have:
I just managed to make suspend working, both to RAM and to Disk, on my ThinkPad T60p. Here's, hopefully, what I did (Debian Unstable):
Compiled kernel 18.104.22.168 with ACPI support, and suspend to ram/disk enabled. My kernel is patched with suspend2, but in the end I had to disable that.
Installed uswsusp, rebuilt initramfs (update-initramfs -u -k 22.214.171.124)
Removed anything suspend2-related. That didn't work, period. It suspended correctly, but upon resume there were a few cases:
- if it was suspend to disk, upon resume I got a segmentation fault, no questions asked.
- if it was suspend to RAM and the system was suspended for no more than a few minutes, resume worked.
- If it was suspended to RAM for more than a few minutes, Xorg would hang on resume with a blank screen. That is, the machine wakes up, the display light turns on, it has network and I can ssh to it, and see Xorg consuming 100% CPU. Trying to kill it won't solve the problem—it just won't die.
I have to add that suspend2 to disk did work, at some point, almost correctly (still got random crashes every now and then). But in any case, I can see why it's not part of the official kernel. It's not stable, period.
Removed gnome-power-manager (on suspend to RAM it says there was a problem suspending the machine, and aborts; on suspend to Disk nothing happens).
Don't bother using s2ram and s2disk either, they don't work.
The only way I can flawlessly suspend is by these simple commands:
# for suspend to RAM: echo -n mem > /sys/power/state # for suspend to disk: echo -n disk > /sys/power/state
Going back to basics. Despite the enormous amount of work on all of those neat tools, like hibernate, suspend2 with it's nice UI that shows you the progress, and s2disk and s2ram, gnome-power and all else, only the commands above have worked. Flawless, that is.
Now I just need to figure out how to make them available on standard keybindings.
Update: I did; quite easy. Just watch your /var/log/acpid log for entries like this when you press your laptop's suspend or hibernate buttons:
[Wed Feb 28 18:11:13 2007] received event "ibm/hotkey HKEY 00000080 00001004" [Wed Feb 28 18:11:13 2007] notifying client 5317[104:107] [Wed Feb 28 18:11:13 2007] notifying client 5687[0:0] [Wed Feb 28 18:11:13 2007] executing action "/etc/acpi/sleepbtn.sh"
This pretty much informs us that /etc/apci/sleepbtn.sh is called when I press the sleep button. I edited it and added "echo -n mem > /sys/power/state" and now suspend works great using the standard button. :)