On Thu, 22 Jun 2006, David Brownell wrote: > > > Fixing that involves updating pm core locking, ISTR. I've thought that > > > the root cause of the issue is that the list of devices to be suspended > > > is created at the wrong time ... very early and globally scoped, not > > > on-demand and privately scoped. > > > > I believe this has been fixed for quite a while. > > That's been said, but nonetheless the last few times I've tried to do > things like handling disconnect processing anything other than very > late (after khubd got woken up again), it was still deadlocksville. > Yes, this is _after_ folk have said "this has been fixed...". I haven't looked at it recently. It shouldn't be too hard to prevent khubd from being frozen and then provoke a disconnect during system resume... I'll let you know what happens. > That applies only during system sleep state transitions. Well yes, of course. We were talking about system sleep, not runtime PM. > If you > try to invoke selective suspend (only part of the driver model tree > rather than the whole thing), all such ordering is ignored. And > for USB, selective suspend is a fundamental mechanism for reducing > systems' runtime power usage. Ben never suggested device creation or removal should be prevented during selective suspend, and you never mentioned encountering any deadlocks because of it. So why do you bring it up? Alan Stern
