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
question.
Greetings,
Rafael
--
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
