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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
