> -----Original Message----- > From: Don Zickus [mailto:dzickus@xxxxxxxxxx] > Sent: Wednesday, November 17, 2010 10:29 PM > To: Sarah Sharp > Cc: Xu, Andiry; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: xhci: suspend/resume issues > > 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. > Don, Can you specify the model of your Buffalo USB3.0 HDD? I've tried a Buffalo HD-HXU3 1.0TB USB3.0 HDD, using 2.6.37-rc1 and force the host controller to re-initialize during S3 resume. Here is the message of the USB3.0 HDD shows during resume: [ 431.260103] hub 6-0:1.0: port 1: status 8103 change 0005 [ 431.370136] usb 6-1: finish reset-resume [ 431.490322] usb 6-1: reset SuperSpeed USB device using xhci_hcd and address 2 And then it works smoothly. Not sure why it indicates a disconnect in your case, but if you are using the same HDD with me, then it may not be the device issue. Thanks, Andiry -- 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
