Suspend2 Suspended

musicon writes "Nigel Cunningham, the creator of the Suspend2 software suspend system for Linux announced his retirement from the project in a message to the Linux Kenel Mailing List. 'Users of Suspend2 can rest assured that I will not allow the patches to suffer bitrot. I will be continuing to use them myself, and will therefore have the best of incentives to keep them up-to-date [...] I won't, however, be making any sort of concerted effort at getting them merged into the vanilla kernel [...] I don't see the point to doing anything but maintaining the patches as they stand.'"

Tragedy

[d99-sbr]

This is something that the Linux kernel badly needs! Presently, suspend and hibernation is at least 5 years behind OS X and Windows.

It takes almost two minutes to hibernate my Thinkpad with 512 MB RAM when running Ubuntu, while Windows takes about 15 seconds. Additionally, it does crash every now and then.

What are the alternatives?

[Rytis]

Is this the only software that can force my Thinkpad R50e to fall asleep? Aren't there any others?
I've compiled 2.6.15.4 kernel and the latest version of Suspend2 is for the 2.6.15.1 version. And now I am not even sure whether the patch is coming in a next month or it isn't coming at all.
Gee, I have to turn it off all the time.

Distributions responsibility

[zaguar]

This is an area where the major distro's - Ubuntu, Mandrake, Suse et al. need to pick up their game. Suspend2 is a great solution, but it is poorly integrated into the vanilla distro's. A few months ago, I tried Suspend2 with Hoary (Ubuntu 5.04) I had to:

1. Download Ubuntu kernel sources
2. Apply a patch-set
3. Recompile the kernel and install the kernel
4. And some other stuff I forgot - involving messing around in /etc and other areas - config files galore!

Now I havent tried it with Breezy, but I am pretty sure there is no .deb/script on UbuntuForums.

Why can't the disto's simply give the user Suspend2 fully integrated in their repective kernels?

Surely not stability issues, because it was bug-free for me. Even a simple choice would be miles better than what the current situation. The distro makers have dropped the ball, let's see them pick it up.

Oh wait - I just said that Ubuntu et al. is not perfect! Goodbye, karma.

Re:Tragedy

[myspys]

suspend and hibernation is at least 5 years behind OS X and Windows

I know hibernation exists in Windows, but OS X?

Can you please enlighten me, since I've totally missed this feature in OS X :-/

I hope you're not talking about Safe Sleep [andrewescobar.com], which is only available in the newer Powerbooks and is not the same thing as hibernation (well, it works the same, but only works on the Powerbooks, where as hibernate works on any Windows PC)

Re:Awww!!!

[gerddie]

There is a suspend as part of the vanilla kernel. I'm using it for quite some time now. Hibernate works on my Laptop, but only if I don't use the binary only nvidia drivers (Geforce2 Go) - and it works on my desktop system too - here even with the nvidia drivers (Geforce 6600) and SMP/Hyperthreading enabled (needs CPU hotplug enabled too). I'm using the hibernate scripts ( (apt-get install | emerge) hibernate) and the /sys/power/state method. Suspend to RAM is not working on my desktop system though.

Re:Tragedy

[brunes69]

Hibernate is suspend to disk.

In Windows there is little reason to use suspend to ram, because suspend to disk is so damn fast (10 seconds down, 15-20 seconds up), and while suspended the laptop uses *0* power.

Like the parent said - suspend to disk in Linux is not in a good state right now. When it *does* work, it does so very slowly. When it *doesn't* work, it's a disaster and sometimes leaves your system in such a weird state you need to hard reboot and fsck your drives.

And don't even think about using it if you use the NVidia drivers.

That's fine.

[Inoshiro]

The correct answer is that the kernel needs to do this, not userland (per suspend1), because of all the layers that need their information preserved. Having any kind of userland help doesn't work, because suddenly you've broken the "every process is equal" approach to the scheduler. But it's also not correct to throw in a huge, complicated interface (suspend2).

The correct answer is something like outlined here [lwn.net]: " If you want my cheerfully uninformed opinion, we should toss both of them out and implement suspend3, which is based on the exec/kdump infrastructure. There's so much duplication of intent here that it's not funny."

You just have to reserve memory for a dump kernel. It's a much better trade off than making the scheduler stupid (suspend1), and keeps your kernel conceptually much simpler than a fancy kernel internal API (suspend2).