On Tue, 16 Nov 2010, 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: > > 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): Surely this is the real problem. Once the device has changed speeds like this, what's the right way to get it to change back to SuperSpeed? Reset the 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 There used to be code to prevent xHCI ports from being disabled. What happened to it? Does it need to be added back in? We had a discussion about this issue some time back, and as I recall, the outcome was that we decided there aren't any situations where usbcore should need to disable a SuperSpeed port. I don't remember if we decided anything about non-SuperSpeed xHCI ports. > 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 This may be where the disconnect occurs, but the driver already reported that the port was disconnected when usbcore polled the status of all four ports just above. > 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. But the ports get reset anyway, as part of the persist handling. How would breaking the root hub into two help? 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
