On Wed, 4 Jul 2007, Alan Stern wrote: > > Threads that do no I/O at all don't care about suspend/resume and > > don't need to be frozen in any case. Threads that issue I/O requests > > in order to service incoming I/O requests can't be frozen because of > > the possibility of deadlock. Which leaves threads that do I/O just > > for the fun of it. :) > > > > What am I missing? > > Those two threads will try to resume USB devices in response to wakeup > requests. Such requests arrive during a suspend or resume transition > more often than one would expect. > > If the resume attempt occurs before the host controller has been > suspended, it will abort the system suspend. If it occurs after the > host controller is suspended (and before the controller resumes) it > will fail and try to unregister the USB device -- something else we > don't like happening while the sytem is only partially up (not to > mention the annoyance caused by the unregistration of a perfectly > functional device).
Actually the situation may not be quite this bad any more. It's been a while since I tried suspending a system without freezing khubd and ksuspend_usbd. But Miklos's mail shows that problems can and will occur. Alan Stern - 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/
