Rafael J. Wysocki (a suspend maintainer) has written an article speaking about the current status of suspend and hibernation support in Linux, its design, know problems, and future development. "Below is a document describing the current state of development of the suspend and hibernation infrastructure: how it works, what known problems there are in it and what the future development plans are (at least as far as I am concerned)."
To read all comments associated with this story, please click here.
Member since:2005-07-06
Member since:2005-09-21
Member since:2005-07-06
Member since:2006-02-05
Member since:2006-03-29
Member since:2006-01-25
I guess I'm also blessed on Linux (well Ubuntu specifically), as power management works perfectly on mine (well at least suspend, I never hibernate so I have no clue if it works, just suspend on lid close, and I'm closer to 100%). On Windows XP, after suspend, the screen backlight will not go on without weird FN key combinations that are somewhat random if it will go back on or not. It actually had the same problem with Linux until g-p-m implemented a workaround for the "hardware bug" about a year back. Now its flawless in Linux, but Windows XP still doesn't work. My laptop won't run Vista at all...
I thought the problems were getting more rare now as long as there is a nvidia card inside, I know I had big problems with this laptop when I was on Gentoo and the early Ubuntu's, but it was fixed before 6.06 (I think for 5.10 if I remember right) and has worked great since.
Not sure how my desktop does with suspend on Linux, never tried really, never had an interest. I think mythtv will wake from suspend to record, so maybe if it is reliable, I can use it to save power (and reduce heat output which would actually be the nice part)
Edited 2007-07-28 04:52
Member since:2005-07-06
Speaking as one of XO laptop tester (for those who don't know, it is OLPC), the machine with the latest development build is able to fully suspend/resume using only HAL and the kernel from Fedora 7 without resorting to suspend2. So far only Fedora 7 (including its XO variant), RHEL5 and Mandriva 2007 support that feature. IMHO, the hal quirk approach is much better than using suspend2. For details:
http://people.freedesktop.org/~hughsient/quirk/
Member since:2006-03-29
Member since:2006-06-29
FWIW, you can use the hal quirks db on Debian too, by installing the pm-utils package. That has nothing to do with suspend2 or not, though.
suspend2 is for suspend to disk (hibernate). The quirks stored in the hal db (fdi files) are mostly to work around broken vga graphics adapters, which need a kick to get properly reinitialized after suspend to ram.
Member since:2005-07-08
And no more time should be spend arguing between kernel devs and user space folks about this
How "arguing between devs and user space folks about this" is going to stop or improve suspend is a mistery to me. What the h*ll does userspace cares about this? Bringing random, unproved FUD from the anti-Linux (which now is trendy in OSNews, apparently) threads here, I guess?
This is pretty much a kernel thing. And it's NOT easy, many efforts have been put in this but the only-microsoft-compatible, unstandard hardware is not so easy to make work as it looks. Proof: Excluding Windows, only Linux has managed to produce a half-working suspend version for standard PC hardware. There's Mac OS X too, but that one is designed for a very small subset of hardware.
Edited 2007-07-27 21:18
Member since:2005-07-06
http://lwn.net/Articles/153609/
Also, this is a first for me - I am apparently part of the anti-Linux thread on OSNews. My friends would find that pretty funny. I love Linux (a song I thing Joan Jett should sing by the way), and healthy criticism is a good thing.
[EDIT: added note about "anti-Linux" comment.
Edited 2007-07-27 21:30
Member since:2005-11-11
Eh, guys, this *is* what Con Kolivas suggested a few stories back (http://osnews.com/story.php/18334/Fork-a-Kernel-Kill-an-OS-and-Revo...). And you guys all flamed him down for that, remember?
Member since:2006-06-15
My Inspiron 8200 has great suspend on Feisty. Actually I wasn't expecting it to work at all, since I'm using the Nvidia binary drivers, and since I've heard so many stories about suspend in Linux, but I didn't even have anything to set up. Next time I buy a laptop, I'll just try if it works, else I'll send it back. It's just too convenient.
Member since:2005-10-13
I got a Dell linux laptop, and suspend works almost perfectly the 1st two times. (Sometimes the headphone jack will stop correctly cutting out the speakers after a resume) The problem occurs on the 3rd resume in a row without rebooting, at which point it never wakes up. I may try disabling the NVIDIA drivers to see if that fixes it.
I haven't had perfect luck on Windows either. My previous laptop would hardly ever successfully hibernate because of a known bug with Windows hibernation on machines with 2GB of RAM. It would suspend correctly, though, which is all I really ever use.
Member since:2005-10-23
Member since:2005-07-08
There must be a standard way for drivers to cooperate with this process - and all the drivers must be required to do so or not be allowed at all
The design doc gives a good overview of this process. Each driver class, type, and bus type can define up to four callbacks: .suspend(), .suspend_late(), .resume_early(), and .resume(). The drivers, their types, and their callbacks execute in a specific order. Any error codes returned during suspend cause the process to abort and all steps to be undone in reverse to restore the working system.
However, it is up to the driver to register the callbacks and do whatever they need to do at the various stages of the suspend/resume cycle. If the driver doesn't do what it needs to do and returns success (or doesn't register a required callback), then the system breaks.
So there is simply no way to "verify" that a driver will properly suspend/resume until it fails. There really isn't any way around this kind of design, either. I used to maintain a kernel component that worked in a similar way, so I've given this a lot of thought. You can fail as gracefully as possible. That's the best-case scenario.
Member since:
2005-07-06
It still is useless for me. I have gone through several laptops with no sucessful standby. Only one laptop had a sucessful hibernate, which I found useless, since it took almost as long as a full bootup. My current desktop, a Core 2 Duo from Dell fails also. It goes to sleep, but video borks on wakeup. Under Windows it sleeps in 1-2 seconds and wakes up in about 5 seconds, no problems.
Personally, I believe as long as the process is dependent on all the drivers cooperating perfectly, it will always be a very hit-and-miss process. There must be a standard way for drivers to cooperate with this process - and all the drivers must be required to do so or not be allowed at all (maybe modprobe fails!).
This is a very serious issue. Laptops without sleep are a joke. Even desktops should sleep to save on power. Linux needs to bump the priority on this and spend a little less time on supporting 1000 processors. And no more time should be spend arguing between kernel devs and user space folks about this. Git 'r done!!