On Thu, Nov 11, 2010 at 02:19:04PM -0500, Don Zickus wrote: > On Thu, Nov 11, 2010 at 05:24:26PM +0800, Xu, Andiry wrote: > > From what I can tell, it seems the port status is wrong after resume. > > > > 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 > > > > 0x280 means the port is disabled. For USB3 port, it should automatically > > transition to Enabled state. As the port is disabled, the host downgrade > > it to USB2 port (port 3), and the following initialization fails. > > Perhaps core driver disable the port somewhere. > > > > One more thing: you are doing system suspend, but the xhci_resume() > > re-initialize the host controller, which means your xHC failed to > > restore state (STS_SRE is set) during resume. Perhaps it's a HW/BIOS > > issue of your platform, normally the restore process should succeed. > > I've encountered similar issue when I was using old BIOS. > > I upgraded my BIOS, well relatively speaking 2005 -> 2006. :-) It did not > change the behaviour. I uploaded the dmesg log to: > > http://people.redhat.com/dzickus/logs/dmesg2.log > > in case you wanted to see. > > I'll try and look for another machine to plug my pci-e card into to see if > I get better luck. I suspect it's probably a USB device-side issue, rather than a host controller or BIOS issue. The xHCI host controller also reports a resume failure for me, but my USB devices do not disconnect. Instead, they report a connected status and get re-enumerated, and mounts stay stable across suspend/resume if USB persist is enabled. A better use of your time might be to find out if other USB devices also disconnect across suspend (both USB 2.0 devices and other USB 3.0 devices). I'm also curious if the USB 3.0 device might not be able to handle USB device suspend (autosuspend). Can you unmount the hard drive, unload the usb-storage driver, and then try to autosuspend it? To autosuspend it, you'll need to find the device's file in /sys/bus/usb/devices; it will be something like 3-2. You can use lsusb to find the vendor and product ID of the device and check the idVendor and idProduct files in each directory to find it. E.g.: sarah@xanatos:/sys/bus/usb/devices/3-2$ lsusb Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 003: ID 0a5c:2145 Broadcom Corp. Bus 003 Device 002: ID 08ff:2810 AuthenTec, Inc. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub sarah@xanatos:/sys/bus/usb/devices/3-2$ cat idVendor 0a5c sarah@xanatos:/sys/bus/usb/devices/3-2$ cat idProduct 2145 So I know I've found my Broadcom Corp. bluetooth device. Once you've found the right directory, echo "auto" to the power/control file. That should autosuspend the USB 3.0 hard drive after 2 seconds. Wait for 5 seconds or so, and then echo "on" to power/control. If the dmesg shows that the device disconnected on resume, it may not be able to handle USB device suspend. That could be the reason it disconnects on resume from hibernate, because the xHCI driver has to put all the devices in USB device suspend before suspending the host controller. The device might also need a reset-resume quirk, but I'd have to stare at the log files and the code to see why this particular bug is happening: xhci_hcd 0000:04:00.0: Can't reset device (slot ID 1) in enabled/disabled state xhci_hcd 0000:04:00.0: Not freeing device rings. xhci_hcd 0000:04:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90012710450, 32'h200e01, 4'hf); xhci_hcd 0000:04:00.0: clear port reset change, actual port 3 status = 0xe03 usb 6-4: new high speed USB device using xhci_hcd and address 4 I think it means reset-resume may not be able to be done under the xHCI host. But, as I said, I have to look deeply at it. Sarah > > > -----Original Message----- > > > From: Don Zickus [mailto:dzickus@xxxxxxxxxx] > > > Sent: Thursday, November 11, 2010 3:54 AM > > > To: Sarah Sharp > > > Cc: Xu, Andiry; linux-usb@xxxxxxxxxxxxxxx > > > Subject: Re: xhci: suspend/resume issues > > > > > > On Tue, Nov 09, 2010 at 01:54:15PM -0800, Sarah Sharp wrote: > > > > > > Hi Sarah, > > > > > > Thanks for the quick response! > > > > > > > > scsi 4:0:0:0: Direct-Access BUFFALO External HDD 0100 PQ: > > 0 > > > ANSI: 5 > > > > > sd 4:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 > > GiB) > > > > ... > > > > > EXT4-fs (sdb2): recovery complete > > > > > EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: > > (null) > > > > > SELinux: initialized (dev sdb2, type ext4), uses xattr > > > > > SELinux: initialized (dev sdb1, type vfat), uses genfs_contexts > > > > > > > > Your device is very unhappy after this point. Perhaps because of > > > > SELinux? Some process is doing *something* with the hard drive that > > the > > > > device doesn't like, even though you say it's not mounted. I've > > never > > > > tried enabling SELinux with a USB 3.0 hard drive, so it's possible > > the > > > > device doesn't like some SCSI command SELinux issues. > > > > > > Ok, I turned SELinux off. It did not seem to make a difference. > > > > > > > > > > > > xhci_hcd 0000:04:00.0: Can't reset device (slot ID 1) in > > > enabled/disabled state > > > > > xhci_hcd 0000:04:00.0: Not freeing device rings. > > > > > usb 6-4: new high speed USB device using xhci_hcd and address 4 > > > > > xhci_hcd 0000:04:00.0: WARN: transfer error on endpoint > > > > > xhci_hcd 0000:04:00.0: WARN: transfer error on endpoint > > > > > xhci_hcd 0000:04:00.0: WARN: transfer error on endpoint > > > > > usb 6-4: device descriptor read/8, error -71 > > > > > > > > And then there's bus noise or the device spewing bad data. > > > > > > > > So, first step is to use the same kernel with more xHCI debugging, > > so I > > > > can see what's up with the device being reset right before the > > suspend. > > > > Then once that's fixed, you can see if turning off SELinux causes > > the > > > > issue to go away. > > > > > > The log was over 2MB in size, so I won't post it here. I also didn't > > know > > > what to cut out for posting, so I stuck it here: > > > > > > http://people.redhat.com/dzickus/logs/dmesg.log > > > > > > Let me know if you need more info. > > > > > > 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
