Hi Tom, I'm the driver xHCI maintainer, and it helps if you Cc me on mail about USB 3.0. Otherwise it gets lost in the noise. :) On Mon, Mar 12, 2012 at 01:23:41PM +0000, Tom Goetz wrote: > I have two machines where the Intel xHCI devices don't wake up from runtime > suspend after a S3 suspend/resume on Xen 4.0.3 and Linux 3.2.9. So the system wakes up from S3, but the host doesn't report any port status changes when you plug in a USB device? > The first is a Ivybridge laptop You do mean Ivy Bridge and not Sandy Bridge, correct? > and after resuming on battery, inserting a > usb device into a port no longer wakes up the xHCI device. Changing the power > mode from "auto" to "on" fixes it. It is not broken on Ubuntu 12.04 Beta 1 with > Linux 3.2.0. Interesting. I've been receiving several reports about suspend failures, but none this specific about the kernel version. Thanks for the clue. Do you see messages about root hub power loss after resume on battery, like these? [ 776.123716] xhci_hcd 0000:00:14.0: setting latency timer to 64 [ 776.123727] usb usb3: root hub lost power or was reset [ 776.123729] usb usb4: root hub lost power or was reset I'm wondering if the host controller is reacting differently based on whether the laptop is powered off of AC or not. Oliver noted some bugs in the S4 power loss resume path, so those might be related. > I have also have a Intel SDP desktop where setting the power mode to "auto" on > the xHCI device does not break device insertion enabling the device on a fresh > boot, but does break it after a S3 resume. > > I have an instrumented kernel and see no rpm_resume for this device int he bad > case. Wake up works fine for devices plugged into EHCI. > > I've also posted this to xen-devel earlier: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00727.html Why were you posting there in particular? You're much more likely to get your USB questions answered on this mailing list. :) Sarah Sharp -- 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
