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

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

 



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.


--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux