On Fri, 23 Jun 2006, David Brownell wrote: > > > > 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...". > > > > Okay, I have tried it. > > Hmm, when I tried that, I did it on suspend() paths not resume, and > the deadlocks were in PM core code. I didn't see that SCSI bug. The SCSI bug is new, probably introduced while adding support for SCSI suspend. The state model didn't allow for a transition from suspended to disconnecting. > Maybe it really is fixed now. I'll have to try calling usb_disconnect during suspend, to make sure that works as well... > > The devices actually get removed twice: once during the "resume so we can > > write out the memory image" phase and then once again during the actual > > final resume. > > ... albeit still strange. Not so strange, since the system's state has been cloned -- complete with the "device should be removed for testing during the upcoming resume" stuff. Alan Stern
