Re: xHCI and suspend/resume

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

 



On Tue, May 17, 2011 at 10:38 AM, Sarah Sharp
<sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:
> On Sun, May 15, 2011 at 12:38:24AM +0200, Rafael J. Wysocki wrote:
>> On Saturday, May 14, 2011, Dwight Schauer wrote:
>> > 2011/5/14 Rafael J. Wysocki <rjw@xxxxxxx>:
>> > > On Saturday, May 14, 2011, Dwight Schauer wrote:
>> > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > >> > On Friday, May 13, 2011, Dwight Schauer wrote:
>> > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote:
>> > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > >> >> >> > On Thursday, May 12, 2011, Rafael J. Wysocki wrote:
>> > >> >> >> >> On Thursday, May 12, 2011, Alan Stern wrote:
>> >
>> > >> >> >> >> > For new readers: The problem is that an xHCI USB host controller does
>> > >> >> >> >> > not wake up a suspended system properly.
>> > ...
>> > >> > So, clearly, you don't get any PCIe PME interrupts from root ports
>> > >> > when the keyboard is plugged in.  Without those interrupts the runtime
>> > >> > resume of xhci won't work.
>> > >> >
>> > >> > Please attach the output of "lspci -vv" with "auto" in the (suspended) xhci's
>> > >> > power/control file before and after you've plugged in the keyboard.
>> > >> >
>> > >> > Thanks,
>> > >> > Rafael
>> > >>
>> > >> The lspci -vv before, after, and diff are attached.
>> > >
>> > > This means that the PME signaled by the xHCI doesn't cause the PMEStatus bit
>> > > in its root port to be set, which is why the root port doesn't generate
>> > > interrupts.  This seriously looks like a hardware bug and the only thing
>> > > we could do to work around it would be to poll the xHCI for the PME status
>> > > periodically (while suspended).
>> > >
>> > > Can you see if the feature works after booting with pcie_ports=compat in
>> > > the kernel command line?
>> > >
>> > > Rafael
>> > >
>> >
>> > I'll try that on Monday (the pcie_ports=compat kernel option).
>> >
>> > Well, I've got 2 different systems (one Intel and one AMD based, both
>> > exhibit the same behavior).
>>
>> Are both xHCI controllers from NEC?
>>
>> > I have a few other systems I can try it on as well on Monday.
>>
>> Please do if possible.
>
> If pcie_ports=compat doesn't help, does it help if you use pci=nomsi?
> I'm wondering if the hardware bug shows up only when MSI or MSI-X is
> enabled for the NEC hardware.  Also, if you turn on
> CONFIG_USB_XHCI_HCD_DEBUGGING, what NEC firmware version do you see in
> dmesg?
>
> Sarah Sharp
>

pcie_ports=compat had no effect
with pci_=nomsi I get upon boot.

xhci_hcd 0000:02:00.0: Failed to enable MSI-X
xhci_hcd 0000:02:00.0: failed to allocate MSI entry
xhci_hcd 0000:06:00.0: Failed to enable MSI-X
xhci_hcd 0000:06:00.0: failed to allocate MSI entry

The 6:00.0 is for NEC device in the PCIe slot.

With pci_=nomsi the rutime power management works, I can put auto in
power/control and the device comes back on it's own.

However, this does not address the wakeup from system suspend issue,
enabled in power/wakeup still does not work. If the interrupt is now
being polled, that would make sense as to why it still does not work.

For TI's xHCI device I get "xhci_hcd 0000:02:00.0: failed to allocate
MSI entry" with pci=nomsi.

The system with TI's device in it is exhibiting the same symptoms
(wakeup does not work and by default auto in power/control does not
work). It is a different motherboard and chip-set than the system I
have the NEC device in.

pci=nomsi has no effect on the system with the TI xHCI device in it.
pcie_ports=compat had no effect either as far as making auto in
power/control work properly.


As to the NEC firmware, both the on-board and off-board NEC devices
have the same version:

xhci_hcd 0000:02:00.0: NEC firmware version 30.21
xhci_hcd 0000:06:00.0: NEC firmware version 30.21

Attached are the dmesg boot logs for both systems.

Dwight Schauer

Attachment: nec-dmesg.log.gz
Description: GNU Zip compressed data

Attachment: ti-dmesg.log.gz
Description: GNU Zip compressed data

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux