[lkml]   [2007]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tuesday, 3 July 2007 16:59, Johannes Berg wrote:
> On Tue, 2007-07-03 at 10:50 -0400, Alan Stern wrote:
> > Time for me to jump in.
> :)
> > USB already implements runtime PM. If a device is suspended at runtime
> > and a task tries to access it, the device is automatically resumed.
> > No problem there.
> Right.
> > The problem comes when the system is doing a STR. Right now the code
> > doesn't keep track of the difference between a runtime suspend and a
> > system suspend -- once the device is suspended, it's suspended, period.
> > Consequently, a non-frozen user task trying to do I/O to a suspended
> > device during STR will cause that device to resume, thereby forcing the
> > system suspend to abort. Something much like this has actually
> > happened and been reported as a bug on LKML (I don't have a URL handy,
> > and it was actually a non-frozen kernel thread interfering with
> > hibernate rather than a non-frozen user task interfering with STR, but
> > the principle is the same).
> Yeah, I can see that happen.
> > Yes, the code could be changed to keep track of the reason for a device
> > suspend. But that just raises the old problem of what to do when
> > there's an I/O request for a suspended device during STR.
> >
> > > I think the core of the discussion isn't appreciated by everybody here
> > > yet---we need to solve both run-time and suspend-to-ram-time device
> > > suspend, not just one of them.
> >
> > Runtime suspend isn't a problem. Only STR.
> Ah but for all those character devices people were saying are the
> problem we haven't even solved runtime suspend as far as I can tell from
> the discussion.
> > Consider a particularly troublesome case: During STR, a non-frozen task
> > writes to /sys/bus/BBB/drivers/DDD/bind. The sysfs core grabs the
> > device semaphore and calls the driver's probe routine. If the driver
> > isn't PM-aware it simply tries to initialize the device and fails
> > because the device is already suspended. That's no good; it isn't
> > transparent.
> >
> > So assume the driver is PM-aware. It tries to resume the device, which
> > fails because STR is underway. Now what can it do? There's only one
> > possibility: It must block until the resume call can succeed. But when
> > is that?
> >
> > It has to be before the PM core tries to resume the device, because the
> > core will try to acquire the device semaphore and will block waiting
> > for the probe call to complete. But it has to be after the PM core
> > resumes the device's parent, because obviously the device can't resume
> > until its parent is awake.
> >
> > As you can see, this is a very difficult problem to solve.
> Indeed. Actually, one could argue that it's impossible to solve the
> problem as long as we try to call out to userspace during suspend and
> need to wait until that's finished, like in the case of sys_sync() and
> fuse filesystems, and probably other cases. Maybe we should make *those*
> calls return a failure so that the suspend isn't transparent inside the
> kernel but is transparent to userspace.

Well, it generally needs more consideration. :-)

I think that we should introduce mechanisms that will allow us to notify all
kernel subsystems, including FUSE and similar, that the system is going to
enter a sleep state (one of those is the notifier chain introduced recently).

Then, they may react to such a notification by entering a "suspend" mode
of operation in which they will return errors from some callbacks that
otherwise should have succeeded etc. That depends on the subsystem in


"Premature optimization is the root of all evil." - Donald Knuth
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-03 17:17    [W:0.335 / U:0.024 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site