On Fri, 17 Dec 2010, Jon 'maddog' Hall wrote: > usbmon trace > > Same actions, started trace at 'safely remove' command, stopped when > filesystems were remounted. All right. I don't know if the explanation for this behavior lies in the xhci-hcd driver or in the drive itself -- my guess is the drive. Here's what happened. The drive was attached to port 2. When you clicked the "safely remove drive" button: The kernel wrote out its dirty pages to the drive (part of the unmount procedure); The kernel sent a SYNCHRONIZE CACHE command (part of the unmount); The kernel sent a STOP UNIT command (part of the unmount); The device was suspended and then immediately resumed; The device was unconfigured; The device was suspended again; The port was disabled (or rather, the kernel tried to disable the port but xhci-hcd didn't actually do it); 2.5 seconds later the root hub was suspended. Up to here, everything happened as one would expect. Then: 2.4 seconds later, the root hub woke up again because of a disconnect event on port 4; Within the next 100 ms, the drive disconnected itself from port 2; After another 0.6 seconds, the drive reconnected itself to port 2. >From that point on, the kernel treated it like any new connection. The drive was enumerated and probed, and it showed up again on the desktop. This sequence of events makes me wonder about the wisdom of skipping the initial port reset in hub_port_init() for SuperSpeed devices. In this case the kernel _thought_ this was an initial reset but it really wasn't. As a result the device didn't get reset when it really should have. The disconnect event on port 4 is suspicious. I guess that port 4 is the low/full/high-speed companion port for port 2. Maybe the device was indulging in some weird signalling. As for the disconnect shortly followed by a reconnect, I expect it's safe to assume that xhci-hcd wouldn't do any such thing by itself. Presumably the device was entirely responsible. Goodness knows why -- as far as the device could tell, it was attached to a suspended SuperSpeed port. There was no reason to unilaterally disconnect. As for fixing the problem, it's not clear that we can do anything about it. If a device decides to disconnect itself from the bus electronically and then to reconnect, the kernel has no way to tell the difference between that and a manual unplug. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
