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). I have a few other systems I can try it on as well on Monday. Dwight _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
