[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xHCI not waking up from D3 after S3 Resume on Ivybridge



On Mar 19, 2012, at 6:11 PM, Sarah Sharp wrote:

> On Mon, Mar 19, 2012 at 05:05:47PM -0400, Tom Goetz wrote:
>> On Mar 19, 2012, at 12:45 PM, Tom Goetz wrote:
>>> On Mar 19, 2012, at 9:32 AM, Tom Goetz wrote:
>>> I've just found that if the xHCI is in D3, has a USB device plugged in, and 
>>> is not waking up, it will wake up when another device in D3 wakes up. 
>>> Here's the steps I followed:
>>> 
>>> 1. S3 suspend
>>> 2. S3 Resume
>>> 3. set xHCI power policy to "auto"
>>> 4. xHCI goes into D3
>>> 5. Plug USB device into xHCI
>>> 6. xHCI does not wake up
>>> 7. set e1000e power policy to "auto"
>>> 8. Unplug ethernet cable
>>> 9. e100e goes into D3
>>> 10. Plug in ethernet cable
>>> 11. Both e1000e and xHCI wake up.
>> 
>> I think xHCI waking from D3 when e1000e wakes from D3 is because they share 
>> the same GPE (0xd). Instrumenting PME polling shows that PME is enabled, but 
>> PME status is never set on the xHCI when a USB device is plugged in.
>> 
>> What can mask PME from firing when it's enabled on the device?
> 
> Intel had a issue with ACPI tables being incorrect in some Ivy Bridge
> systems.  This led to the kernel ignoring PMEs from the xHCI host
> controller because it didn't know the PME was associated with the xHCI
> PCI device.  That ACPI table fix was supposed to make it into the Intel
> reference BIOS.  Have you tried updating your BIOS?

Was running last months. Updated today. Still happens.

> 
> However, the kernel was patched to wake up all PCI devices under the PCI
> bridge that reported a spurious PME, so you shouldn't even need the BIOS
> update.  See commit 379021d5c0899fcf9410cae4ca7a59a5a94ca769 "PCI / PM:
> Extend PME polling to all PCI devices".

I've looked at the that code. I instrumented it to verify that PME was enabled 
and PME status was never set.

> 
> I don't know why a Linux kernel with that fix that's hosted by Xen
> wouldn't work when it worked natively.  Perhaps Xen blocks the spurious
> PME before it reaches the kernel?
> 
> Can you post the ACPI tables, both before and after suspend, on both the
> native Linux install and Xen?

I'm assuming you meant the contents of /sys/firmware/acpi. I had previously 
dumped the DSDT pre and post S3 and not seen any differences.

Here are links to zip files of the contents of /sys/firmware/acpi for each 
situation:

http://dl.dropbox.com/u/68173361/Work/acpi_native_postS3.zip
http://dl.dropbox.com/u/68173361/Work/acpi_native_preS3.zip
http://dl.dropbox.com/u/68173361/Work/acpi_xen_preS3.zip
http://dl.dropbox.com/u/68173361/Work/acpi_xen_postS3.zip

> 
> Sarah Sharp

Thanks for all of the help.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.