On Fri, 10 Dec 2010, Jon 'maddog' Hall wrote: > Alan, > > >You should plug the device into one of the USB-3 sockets, then after 10 > >seconds or so start a trace, then click on "Safely remove drive", and > >then after 10 more seconds unplug the device. At that point stop the > >trace and begin a new one. For the second trace, plug the device back > >into the same socket as before, and when nothing happens try plugging > >it into the other USB-3 socket. > > Compressed tar file per your request. Okay, very good. This shows exactly what the "Safely remove drive" button does: The drive is unmounted; A "spin-down" command is sent (obviously it doesn't do anything for a flash drive); A SYNCHRONIZE CACHE comand is sent, perhaps as part of the unmount procedure; The USB port is suspended and then immediately resumed (no idea why); The device is set to config 0, i.e., unconfigured; The USB port is suspended again (no idea why); The USB port is disabled, presumably by writing to the "remove" sysfs attribute; The port status is read; it shows connected but not enabled. Two seconds later the root hub suspends. Sarah, how good is the bus_suspend support in this version of xhci-hcd? There is no hint in the traces of the device being unplugged and plugged back into the same port. Apparently the suspended root hub does not generate a wakeup IRQ when that port's connect status changes, although it does generate an interrupt when the device is plugged into the second port (and the first port still shows a Connect-Change status). Maybe the port-disable messed up something related to IRQ generation when the root hub is suspended; I don't know. At this point I'm handing the baton back to Sarah. 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
