It is so damn annoying to spend hours trying to fix something which appears to be so simple (and which happens to work perfectly on that other OS) without even getting anywhere. Software suspend has been problematic in linux for years, and that's really why I've never insisted on fixing it on my laptop. But enough is enough, and today I decided I was going to fix it once and for all. Easier said that done.

Like I said, it has been years since people started trying to get this working and there's now tons of howtos and personal stories about what they did and what worked. Of course, just about everything that people say is model specific and what works for one laptop is not sure to work for any other etc. The number of options alone underlines that problem. But it seems that the most widely used (or should I assume the method that has the widest catchment area) is suspend2. So I started out with that, suspend2-sources, setting up the kernel etc. Of course, the more refined your setup is, the more pain you are about to receive. I have a nice framebuffer with a boot screen, which I dumped along the way just to simplify things.

suspend2 in my case was incredibly flaky. Hibernating would work once, the next time it would freeze at "Doing atomic copy" and I'd have to hard boot. I experimented a lot in the console with this, not being able to find any combination of settings that worked reliably. There is a log file for the application, but even setting the logging verbosity to the maximum would only print what it was doing before actually suspending (and then nothing about why the suspending itself failed). Adding fglrx to the equation, as I had feared, was a definite suicide move. Attempting to hibernate with fglrx loaded would consistently kernel panic (is that a verb yet? let's make it one!) and there's no way (that I'm aware of) to keep X running while unloading fglrx.

So much for suspend2. Then there's still Software Suspend. I don't recall having tried this before, somehow it was always described as obsolete and not recommended. The thing is that suspend2 comes with scripts and a bunch of config files, suspend[1] doesn't, so it wasn't too clear how to actually suspend the system. Trying to hibernate with suspend[1] was not a great deal more successful, hibernation seemed to work, but resuming was not always blissful. Again lots of hard boots and I was getting really sick of it. Reading what people had said about my particular video card didn't seem to help at all.

Then I came across suspend to ram in /sys/power/state (which is actually what I wanted, rather than hibernation which requires you to go through grub and all). It turns out this method actually resembles the Windows suspend, you suspend, screen goes blank, power is cut. Then you press the power button, desktop appears right away. Perfect. This isn't software suspend at all (which seems to focus on hibernation), this is acpi sleep. I still need the suspend2-sources, but I can disable everything called 'software suspend'.

At last, after hours of trial and error, scrambling for information on google and reading outdated documentation, I had found the answer. This suspend-to-ram works beautifully even with fglrx (unlike suspend2's 'to-ram' function which never worked for me once). So now I wanted to map this function to a spare button I have on my keyboard and mapping aside, this was a lot harder than expected.

The suspend function is a simple echo mem > /sys/power/state, but, of course, it takes root privileges. This works fine on the command line, but putting that line into a script just didn't work, the screen would go blank, but power wasn't cut, it was as if it waited for the command to terminate first. How ridiculous! So while people had just put that line into a suspend script, it wasn't working in my case. I finally landed on using

sudo bash -c "echo -n mem > /sys/power/state" &

in combining sudo with & to make sure it wouldn't wait for termination. And this put into /usr/local/bin/suspend.sh, mapped to my spare keyboard key actually works now, I finally have software suspend (or sleep, or whatever you call it) working as it should. There's no hibernation, which doesn't bother me as I don't need it.

There's still a small hitch when running suspend.sh in the console. When resuming, the screen is just blank. I can start X and this will make the video card start drawing, which brings the display back to life. Then if I kill X, I have my console visible again. I don't know if this has to do with using a framebuffer or something else, but I can live with it, suspending in X is the whole point of this anyway.

So if you have a Dell Inspiron 6400, here's a suspend-to-ram method that works-for-me (and will probably be outdated by the time you find it, making it useless to you). Enjoy!

UPDATE: No, it's definitely broken. I don't think my soundcard handles suspend very well (or at least the driver doesn't seem to), so I can't suspend if I want my sound working after resuming. Of course, in Windows it works without a hitch. :lazy: Meanwhile, I still have no software suspend..