Okay, good. It's not a coincidence that the first one worked and later
ones didn't. Here's what happened:
You suspended the system. Upon resuming, the USB host controller
drivers detected that their device sessions had been interrupted and
consequently marked your two USB devices (the optical mouse and the
biometric thingy) for removal. Normally that removal would take place
when khubd wakes up, i.e., after the resume is complete and the thread
is taken out of the freezer.
But in this case khubd was already awake. It resumed the two root hubs
in response to their remote wakeup requests and saw that the devices
were gone. So it unregistered the device structures immediately --
even before the PM core tried to resume them -- and then registered new
data structures to embody the new device connections. As far as I can
tell, the fact that these new device structures were created while the
suspend-list was in flux must have caused one of them (the biometric
coprocessor) not to be added to the appropriate list.
Thus the next time you tried to suspend, the PM core didn't call the
device's suspend method. It was left awake, and as a result its parent
hub refused to suspend (since it had an unsuspended child). This
caused the overall system suspend to fail.
This illustrates the folly of allowing other threads to perform
driver-core-type operations in the middle of a system sleep transition.
Alan Stern
-
