>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. Thanks & Best regards, Andiry > -----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
