On Fri, Dec 10, 2010 at 02:50:14PM -0500, Alan Stern wrote: > 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; I'll have to double check if the bandwidth configuration code properly handles this case. I'm wondering if the device slot gets deallocated in this case, and the port resume code gets confused when a new device gets plugged in. > > 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? Maddog has the latest xhci-hcd code (2.6.37-rc5). It's supposed to work, but the code is new. > 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. Maddog, the log you sent me does show the warning-level xHCI debugging messages, but not the debug-level messages. Can you double check that CONFIG_USB_XHCI_HCD_DEBUGGING=y and run `sudo dmesg -n 8`? If you've got that set up correctly, you should be able see messages like [ 168.188155] xhci_hcd 0000:01:00.0: Port Status Change Event for port 3 If not, you have something mis-configured. Perhaps use `tail -f /var/log/kern.log` instead of dmesg in that case? I'd like to see detailed messages from the xHCI driver when you safely remove the device, unplug it, and then replug it in. That should show whether the xHCI driver is actually receiving an interrupt on the reconnect, and what's actually going on with the suspend/resume/suspend issue. Sarah Sharp -- 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
