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 17, 2012, at 1:50 PM, Konrad Rzeszutek Wilk wrote:

>>>>> 
>>>>> Does the xHCI host work fine without Xen?  I.e. running Linux directly
>>>>> as the host OS, suspending, resuming, and then plugging in a device?
>>>> 
>>>> It works in Ubuntu 12.04 Beta 1 with Linux 3.2.0. So it's either broken between 3.2.0 and 3.2.5 or it's broken in Xen. I haven't made a direct comparison yet. I'm putting Ubuntu on my SDP now to test that.
>>> 
>>> xHCI wakes up from D3 on the SDP with Ubuntu 12.04 Beta 1 and 3.2.11. This fails with the same 3.2.11 kernel and Xen. So the problem is Xen related.
> 
> 
>> 
>> Another update.
>> 
>> On the Ivybridge laptop, xHCI is not waking up because when I plug a device into a xHCI port the ACPI wakeup events are going to the e1000e. Pre S3, it eventually gets a interrupt from the device that wakes it up. Post S3 it never gets an interrupt from the device.
> 
> So these are all MSI related issues right.

Maybe.

> The e1000e is also MSI?

Yes. The e1000e getting the xHCI's wake ups is only on one machine. I assume thats a BIOS bug. The broad based issue is that on two manufacturers Ivybridge plus an Intel SDP Ivybridge, xHCI will not wake up from D3 when a USB device is plugged in.

> In
> other words the issues you are having is that the MSI after resume are
> not delivered - but some are ?

Only D3 wake ups (ACPI and PME) are not being delivered. If I change the runtime power policy for the device from "auto" to "on" xHCI works fine.

> 
> If you print out the MSI vector table (from xen) before and resume are
> the vectors the same?

No.

< (XEN)    IRQ:  24 affinity:00000000,00000000,00000000,00000001 vec:c8 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:279(----),
< (XEN)    IRQ:  25 affinity:00000000,00000000,00000000,00000001 vec:61 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:278(----),
---
> (XEN)    IRQ:  24 affinity:00000000,00000000,00000000,00000001 vec:69 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:279(----),
> (XEN)    IRQ:  25 affinity:00000000,00000000,00000000,00000001 vec:71 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:278(----),
29,30c29,30
< (XEN)    IRQ:  28 affinity:00000000,00000000,00000000,00000001 vec:39 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:275(----),
< (XEN)    IRQ:  29 affinity:00000000,00000000,00000000,00000001 vec:41 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:274(----),
---
> (XEN)    IRQ:  28 affinity:00000000,00000000,00000000,00000001 vec:79 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:275(----),
> (XEN)    IRQ:  29 affinity:00000000,00000000,00000000,00000001 vec:91 type=PCI-MSI         status=00000010 in-flight=0 domain-list=0:274(----),


> Is there a pending bit set on the one that are
> not woken up?

No

The thing that confuses it for me is that the device works fine outside of D3. If the MSI was routed incorrectly after S3, then why does it work outside of D3 resume?

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