On Tue, Nov 16, 2010 at 02:09:10PM -0800, Sarah Sharp wrote: > Ok, I think I see what's happening in your log. It is a software > problem. > > The important bit of information is that if a USB 3.0 device doesn't > detect the SuperSpeed terminations, it will switch ports over to the > high speed port. Once it's in High Speed mode, it will only go looking > for SuperSpeed terminations during a device reset. > > The USB core is used to being able to disable ports, and then later > notice a connect change on the disabled port. But if the USB core > attempts to disable a USB 3.0 port, then the SuperSpeed terminations are > turned off, and the device never connects as a SuperSpeed device, only > as a High Speed device. And that's what happens with your device: > > I can tell it originally connected on port 1: > > xhci_hcd 0000:04:00.0: set port reset, actual port 1 status = 0x1311 > > There's a couple of SCSI commands the device doesn't like during the PM > sync of filesystems, and the device gets reset twice. But it comes back > fine, so that's not the problem. > > There's a power loss during suspend (or the BIOS mucked with the xHCI > host controller), and the xHCI host is re-initialized: it's a 5 year old Dell box, the BIOS most likely has no idea about the xHCI card sitting on its PCIe bus. :-) > > usb usb6: root hub lost power or was reset > > At this point, the device has migrated from port 1 (a SuperSpeed port) > to port 3 (a High Speed port): > > xhci_hcd 0000:04:00.0: get port status, actual port 0 status = 0x2a0 > xhci_hcd 0000:04:00.0: Get port status returned 0x100 > xhci_hcd 0000:04:00.0: get port status, actual port 1 status = 0x2a0 > xhci_hcd 0000:04:00.0: Get port status returned 0x100 > xhci_hcd 0000:04:00.0: get port status, actual port 2 status = 0x2a0 > xhci_hcd 0000:04:00.0: Get port status returned 0x100 > xhci_hcd 0000:04:00.0: get port status, actual port 3 status = 0x202e1 > xhci_hcd 0000:04:00.0: Get port status returned 0x10101 > > The USB core is trying to do something sneaky and persist USB devices > across suspend. But since the original port (port 1) reports a > disconnect, it assumes the device isn't there and disables the port: > > xhci_hcd 0000:04:00.0: disable port, actual port 1 status = 0x2a0 > > Only then do we get a device disconnect on port 1: > > xhci_hcd 0000:04:00.0: get port status, actual port 1 status = 0x280 > xhci_hcd 0000:04:00.0: Get port status returned 0x100 > usb 6-2: USB disconnect, address 3 > > The USB core tries to enumerate the device as a High Speed device, but > the device is unresponsive: > usb 6-4: device descriptor read/8, error -61 > > The end result is that the USB 3.0 terminations are permanently > disabled, and the device is stuck at High Speed. That would be > consistent with your observation that a system reboot is required to get > the device to connect at SuperSpeed again. I'm not sure if simply > unloading the xHCI driver and reloading it would help. > > > The real fix for this is to separate the xHCI roothub into two hubs: a > USB 3.0 hub and a USB 2.0 hub. This is how an external USB 3.0 hub > looks like to the system (two separate devices). Then on resume, we can > look at the USB 2.0 hub ports first, reset any of the ports that report > a connection, and then deal with USB 3.0 devices that migrated over from > High Speed to SuperSpeed. > > I've been working on that code, but it's about 700 lines of code right > now, and I'm not done with it, so I don't know if it can make it into > 2.6.37. > > The simple fix might be to have the xHCI secretly not allow the USB core > to disable ports. That needs a couple of the patches from my roothub > separation patchset, but it shouldn't be nearly as large. But I'm not > sure it's going to fix your issue, since the device migrated over to > High Speed. I think that means you'll get the device back at > SuperSpeed, but file systems will not persist across suspend. > > I'll send you the simple patch in a few. Ok. Thanks for all your help. I'll wait for your patches and try and test them quickly. Cheers, Don -- 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
