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: 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. 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
