|
A new suspend/hibernate infrastructureA new suspend/hibernate infrastructurePosted Mar 20, 2008 10:25 UTC (Thu) by tialaramex (subscriber, #21167)Parent article: A new suspend/hibernate infrastructure
I've had more or less working suspend & hibernate on this Z60m for some time now, and before that on an X31. Both machines have suffered some problems from kernel bugs or (more rarely but often longer lasting) userspace trouble. In fact the X31's trouble was dominated by a faulty lid switch (poor design by IBM) which took to declaring that the lib had been opened while the laptop was in fact closed and supposedly asleep, waking the machine while inside bags or being carried about and creating a fire hazard. This bug, at least, can't be laid at the door of any Free Software developers. The most serious bug in the last six months was losing ACLs on my audio devices after a restore. This was found to be a race condition in userspace software and fixed, but not without months of annoyance. But always it comes back to this: Suspending, especially to RAM, is merely a convenience. So it has to be /really/ reliable to be worth having. A lot of the time, my laptops weren't in the state where I could claim that, but it has definitely been getting better. Oh, and to address the initial statistic offered, it occurs to me that a lot of people might be just one or two drivers from working suspend. So the effort to get from say 10% of attendees having working suspend to 90% may actually just be concentrated in one or two key places. The nVidia drivers, of all sorts, seem to be notoriously twitchy about suspending.
(Log in to post comments)
A new suspend/hibernate infrastructure Posted Mar 20, 2008 13:39 UTC (Thu) by nescafe (subscriber, #45063) [Link] If you are running a fairly recent nvidia binary driver (100.x.x or higher), most of the flakiness is attributable to the quirks that the suspend/resume infrastructure runs, which duplicate (badly) or race with the tasks the nvidia driver performs. Once I got rid of those, suspend/resume worked great on my system.
A new suspend/hibernate infrastructure Posted Mar 20, 2008 16:17 UTC (Thu) by ebiederm (subscriber, #35028) [Link] The fact that we confuse the driver methods for putting the hardware in a low power state (suspending) and the driver methods for quiescing a device and being prepared for it to disappear results in unfixable infrasturcture bugs and unclear semantics. So the current set of suspend/resume and hibernate operations must be reexamined if we are to have something that is sane, and generally implentable. Just a few more drivers is a nice idea. But the driver authors can't do that if we don't have clear expectations of what the functions they are supposed to implement should do. In fact except for some goofy corner cases. We should be able to get away with no operations for hibernation. The fact that the last propsal has more driver methods for hibernation shows that the design while it may be sane from the infrastructure point of view. Still has a ways to go before it makes sense from a driver and mainteance point of view.
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.