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. Thanks, Don > > 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
