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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
