A new suspend/hibernate infrastructure

Posted 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.

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.