| Message ID | BANLkTi=XzZsQeBR8-sm9gLjh_Tbyp5LWMg@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Saturday, May 14, 2011, Dwight Schauer wrote: > On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Friday, May 13, 2011, Dwight Schauer wrote: > >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > On Friday, May 13, 2011, Dwight Schauer wrote: > >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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. > >> >> >> > > >> >> >> > On Thu, 12 May 2011, Dwight Schauer wrote: > >> >> >> > > >> >> >> > > Thanks Alan. > >> >> >> > > > >> >> >> > > OK, this is with 2.6.39-rc7-gregkh > >> >> >> > > > >> >> >> > > 05:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host > >> >> >> > > Controller (rev 03) (prog-if 30 [XHCI]) > >> >> >> > > Subsystem: Melco Inc Device 0241 > >> >> >> > > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > >> >> >> > > ParErr- Stepping- SERR+ FastB2B- DisINTx+ > >> >> >> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > >> >> >> > > <TAbort- <MAbort- >SERR- <PERR- INTx- > >> >> >> > > Interrupt: pin A routed to IRQ 17 > >> >> >> > > Region 0: Memory at fe9fe000 (64-bit, non-prefetchable) [size=8K] > >> >> >> > > Capabilities: [50] Power Management version 3 > >> >> >> > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > >> >> >> > > PME(D0+,D1-,D2-,D3hot+,D3cold-) > >> >> >> > > Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME+ > >> >> >> > > >> >> >> > That's the important part for power management and wakeup. The > >> >> >> > controller does support PCI wakeup. In fact, at the time you ran lspci > >> >> >> > the controller _was_ suspended and it was signalling a wakeup request! > >> >> >> > Obviously something is wrong somewhere... > >> >> >> > > >> >> >> > > @@@ With "on" in power/control I get this upon plugging in a keyboard: > >> >> >> > ... > >> >> >> > > @@@ and upon removing it: > >> >> >> > > >> >> >> > All normal. > >> >> >> > > >> >> >> > > @@@ If I put "auto" in power/control I get this: > >> >> >> > > > >> >> >> > > xhci_hcd 0000:05:00.0: hcd_pci_runtime_suspend: 0 > >> >> >> > > xhci_hcd 0000:05:00.0: PME# enabled > >> >> >> > > >> >> >> > This means the controller was suspended with wakeup enabled, as it > >> >> >> > should be. > >> >> >> > > >> >> >> > > @@@ Upon plugging in a keyboard nothing. > >> >> >> > > >> >> >> > Indeed, that is a problem. Since wakeup doesn't work right at runtime, > >> >> >> > it's not surprising that it also fails during system sleep. > >> >> >> > > >> >> .... > >> >> >> > > >> >> >> > Clearly something is wrong. But it looks like the problem might be > >> >> >> > somewhere else, not in the xHCI driver. Is your BIOS up to date? > >> >> >> > > >> >> >> > CC-ing the linux-pm mailing list in case anybody there has some ideas. > >> >> >> > >> >> >> I need a boot log from 2.6.39-rc6 (or current Linus') on the affected system. > >> >> > > >> >> > That should have been -rc7, sorry. > >> >> > > >> >> > Thanks, > >> >> > Rafael > >> >> > >> >> Rafael, > >> >> > >> >> I updated the BIOS, but the results are the same. > >> > > >> > I'm not really sure if that matters. > >> > > >> > Thanks for the boot log. > >> > > >> > Please send the contents of /proc/interrupts before and after you've tried > >> > to resume the xHCI controller. > >> > > ... > >> > >> @@@ plug keyboard back in > >> > >> cat /proc/interrupts > >> CPU0 CPU1 CPU2 CPU3 > >> 0: 160 2 444 122646 IO-APIC-edge timer > >> 1: 0 0 1 7 IO-APIC-edge i8042 > >> 4: 0 0 0 2 IO-APIC-edge > >> 8: 0 0 1 112 IO-APIC-edge rtc0 > >> 9: 0 0 0 2 IO-APIC-fasteoi acpi > >> 16: 0 0 0 439 IO-APIC-fasteoi hda_intel > >> 17: 0 0 0 4 IO-APIC-fasteoi > >> ehci_hcd:usb1, ehci_hcd:usb3, ehci_hcd:usb6 > >> 18: 0 0 4 669 IO-APIC-fasteoi > >> ahci, ohci_hcd:usb8, ohci_hcd:usb9, ohci_hcd:usb10, ohci_hcd:usb11, > >> radeon > >> 19: 0 1 385 25596 IO-APIC-fasteoi > >> pata_jmicron, hda_intel > >> 40: 0 0 0 0 PCI-MSI-edge PCIe PME > >> 41: 0 0 0 0 PCI-MSI-edge PCIe PME > >> 42: 0 0 0 0 PCI-MSI-edge PCIe PME > >> 43: 0 0 0 0 PCI-MSI-edge PCIe PME > >> 44: 0 0 0 1 PCI-MSI-edge xhci_hcd > >> 45: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 46: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 47: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 48: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 49: 0 0 1 93 PCI-MSI-edge xhci_hcd > >> 50: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 51: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 52: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 53: 0 0 0 0 PCI-MSI-edge xhci_hcd > >> 54: 0 0 53 10289 PCI-MSI-edge ahci > >> 55: 0 0 266 71934 PCI-MSI-edge eth0 > >> NMI: 0 0 0 0 Non-maskable interrupts > >> LOC: 25130 27508 14608 1864 Local timer interrupts > >> SPU: 0 0 0 0 Spurious interrupts > >> PMI: 0 0 0 0 Performance > >> monitoring interrupts > >> IWI: 0 0 0 0 IRQ work interrupts > >> RES: 15335 8131 5912 13899 Rescheduling interrupts > >> CAL: 95 138 135 60 Function call interrupts > >> TLB: 225 475 475 194 TLB shootdowns > >> TRM: 0 0 0 0 Thermal event interrupts > >> THR: 0 0 0 0 Threshold APIC interrupts > >> MCE: 0 0 0 0 Machine check exceptions > >> MCP: 18 18 18 18 Machine check polls > >> ERR: 0 > >> MIS: 0 > > > > 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
2011/5/14 Rafael J. Wysocki <rjw@sisk.pl>: > On Saturday, May 14, 2011, Dwight Schauer wrote: >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > On Friday, May 13, 2011, Dwight Schauer wrote: >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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
On Saturday, May 14, 2011, Dwight Schauer wrote: > 2011/5/14 Rafael J. Wysocki <rjw@sisk.pl>: > > On Saturday, May 14, 2011, Dwight Schauer wrote: > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > On Friday, May 13, 2011, Dwight Schauer wrote: > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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. Thanks, Rafael
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@sisk.pl>: > > > On Saturday, May 14, 2011, Dwight Schauer wrote: > > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> > On Friday, May 13, 2011, Dwight Schauer wrote: > > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: > > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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
On Tue, May 17, 2011 at 10:38 AM, Sarah Sharp <sarah.a.sharp@linux.intel.com> 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@sisk.pl>: >> > > On Saturday, May 14, 2011, Dwight Schauer wrote: >> > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > >> > On Friday, May 13, 2011, Dwight Schauer wrote: >> > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: >> > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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
On Tuesday, May 17, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 10:38 AM, Sarah Sharp > <sarah.a.sharp@linux.intel.com> 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@sisk.pl>: > >> > > On Saturday, May 14, 2011, Dwight Schauer wrote: > >> > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > >> > On Friday, May 13, 2011, Dwight Schauer wrote: > >> > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: > >> > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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. OK, so for the S3 issue, I think there's a problem with the PCIe link on these devices such that the link is not present during resume and that's why commands are not reaching the device. I'm not sure yet what to do about it, but I wonder if xhci_hcd does something around PCIe links on suspend? Rafael
On Tuesday, May 17, 2011, Rafael J. Wysocki wrote: > On Tuesday, May 17, 2011, Dwight Schauer wrote: > > On Tue, May 17, 2011 at 10:38 AM, Sarah Sharp > > <sarah.a.sharp@linux.intel.com> 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@sisk.pl>: > > >> > > On Saturday, May 14, 2011, Dwight Schauer wrote: > > >> > >> On Fri, May 13, 2011 at 3:37 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> > >> > On Friday, May 13, 2011, Dwight Schauer wrote: > > >> > >> >> On Fri, May 13, 2011 at 3:04 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> > >> >> > On Friday, May 13, 2011, Dwight Schauer wrote: > > >> > >> >> >> On Thu, May 12, 2011 at 5:29 PM, Rafael J. Wysocki <rjw@sisk.pl> 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. > > OK, so for the S3 issue, I think there's a problem with the PCIe link > on these devices such that the link is not present during resume > and that's why commands are not reaching the device. I'm not sure yet > what to do about it, but I wonder if xhci_hcd does something around > PCIe links on suspend? It doesn't seem so. Dwight, can you comment out the pci_disable_device(pci_dev); in drivers/usb/core/hcd-pci.c and see if that makes a difference? Rafael
On Tue, May 17, 2011 at 3:03 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Tuesday, May 17, 2011, Rafael J. Wysocki wrote: >> On Tuesday, May 17, 2011, Dwight Schauer 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. >> >> OK, so for the S3 issue, I think there's a problem with the PCIe link >> on these devices such that the link is not present during resume >> and that's why commands are not reaching the device. I'm not sure yet >> what to do about it, but I wonder if xhci_hcd does something around >> PCIe links on suspend? > > It doesn't seem so. > > Dwight, can you comment out the pci_disable_device(pci_dev); in > drivers/usb/core/hcd-pci.c and see if that makes a difference? > > Rafael I just tried that, but it has no effect on wakeup from S3. Dwight
On Tuesday, May 17, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 3:03 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Tuesday, May 17, 2011, Rafael J. Wysocki wrote: > >> On Tuesday, May 17, 2011, Dwight Schauer 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. > >> > >> OK, so for the S3 issue, I think there's a problem with the PCIe link > >> on these devices such that the link is not present during resume > >> and that's why commands are not reaching the device. I'm not sure yet > >> what to do about it, but I wonder if xhci_hcd does something around > >> PCIe links on suspend? > > > > It doesn't seem so. > > > > Dwight, can you comment out the pci_disable_device(pci_dev); in > > drivers/usb/core/hcd-pci.c and see if that makes a difference? > > > > Rafael > > I just tried that, but it has no effect on wakeup from S3. OK, one more test, please. Try to do # echo core > /sys/power/pm_test # echo mem > /sys/power/state (that should simulate suspend, but without going into the BIOS, and it should return do the command prompt after 5-10 sec.) and check if the USB3 controllers work after that ("echo none > /sys/power/pm_test" resets to the normal suspend behavior). Thanks, Rafael
On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Tuesday, May 17, 2011, Dwight Schauer wrote: >> On Tue, May 17, 2011 at 3:03 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > On Tuesday, May 17, 2011, Rafael J. Wysocki wrote: >> >> On Tuesday, May 17, 2011, Dwight Schauer 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. >> >> >> >> OK, so for the S3 issue, I think there's a problem with the PCIe link >> >> on these devices such that the link is not present during resume >> >> and that's why commands are not reaching the device. I'm not sure yet >> >> what to do about it, but I wonder if xhci_hcd does something around >> >> PCIe links on suspend? >> > >> > It doesn't seem so. >> > >> > Dwight, can you comment out the pci_disable_device(pci_dev); in >> > drivers/usb/core/hcd-pci.c and see if that makes a difference? >> > >> > Rafael >> >> I just tried that, but it has no effect on wakeup from S3. > > OK, one more test, please. > > Try to do > > # echo core > /sys/power/pm_test > # echo mem > /sys/power/state > > (that should simulate suspend, but without going into the BIOS, and it > should return do the command prompt after 5-10 sec.) and check if the > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets > to the normal suspend behavior). > > Thanks, > Rafael No problem. The simulated suspend works fine. Also, waking up from S3 via a PS/2 keyboard works fine. Dwight
On Tuesday, May 17, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: ... > > > > OK, one more test, please. > > > > Try to do > > > > # echo core > /sys/power/pm_test > > # echo mem > /sys/power/state > > > > (that should simulate suspend, but without going into the BIOS, and it > > should return do the command prompt after 5-10 sec.) and check if the > > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets > > to the normal suspend behavior). > > > > Thanks, > > Rafael > > No problem. > > The simulated suspend works fine. Good. > Also, waking up from S3 via a PS/2 keyboard works fine. Hmm. Do you mean that the USB3 controllers work after the resume if the box has been woken up via the keyboard and they don't work when it has been woken up via a power button? Rafael
On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Tuesday, May 17, 2011, Dwight Schauer wrote: >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > ... >> > >> > OK, one more test, please. >> > >> > Try to do >> > >> > # echo core > /sys/power/pm_test >> > # echo mem > /sys/power/state >> > >> > (that should simulate suspend, but without going into the BIOS, and it >> > should return do the command prompt after 5-10 sec.) and check if the >> > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets >> > to the normal suspend behavior). >> > >> > Thanks, >> > Rafael >> >> No problem. >> >> The simulated suspend works fine. > > Good. > >> Also, waking up from S3 via a PS/2 keyboard works fine. > > Hmm. Do you mean that the USB3 controllers work after the resume if > the box has been woken up via the keyboard and they don't work when it > has been woken up via a power button? > > Rafael They work either way. I'm just not able to get the USB keyboard that is connected to the USB3 controller to perform the wakeup. (Which is what I thought I made clear from the beginning and what Alan Stern had reiterated for new readers further into the thread). Dwight Schauer
On Wednesday, May 18, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Tuesday, May 17, 2011, Dwight Schauer wrote: > >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > ... > >> > > >> > OK, one more test, please. > >> > > >> > Try to do > >> > > >> > # echo core > /sys/power/pm_test > >> > # echo mem > /sys/power/state > >> > > >> > (that should simulate suspend, but without going into the BIOS, and it > >> > should return do the command prompt after 5-10 sec.) and check if the > >> > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets > >> > to the normal suspend behavior). > >> > > >> > Thanks, > >> > Rafael > >> > >> No problem. > >> > >> The simulated suspend works fine. > > > > Good. > > > >> Also, waking up from S3 via a PS/2 keyboard works fine. > > > > Hmm. Do you mean that the USB3 controllers work after the resume if > > the box has been woken up via the keyboard and they don't work when it > > has been woken up via a power button? > > > > Rafael > > They work either way. I'm just not able to get the USB keyboard that > is connected to the USB3 controller to perform the wakeup. (Which is > what I thought I made clear from the beginning and what Alan Stern had > reiterated for new readers further into the thread). Oh, I must have missed that information. Sorry about that. So, the situation is that if you set up the USB3 controllers to wake up and next you wake up the system from S3 using a USB device connected to one of those controllers, then they appear to be in D3 after the resume and apparently cannot be put into D0. However, if the wakeup is done in any different way, they work correctly after the resume, right? Is that the case on both the affected systems? Rafael
On Tue, May 17, 2011 at 5:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Wednesday, May 18, 2011, Dwight Schauer wrote: >> On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > On Tuesday, May 17, 2011, Dwight Schauer wrote: >> >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > ... >> >> > >> >> > OK, one more test, please. >> >> > >> >> > Try to do >> >> > >> >> > # echo core > /sys/power/pm_test >> >> > # echo mem > /sys/power/state >> >> > >> >> > (that should simulate suspend, but without going into the BIOS, and it >> >> > should return do the command prompt after 5-10 sec.) and check if the >> >> > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets >> >> > to the normal suspend behavior). >> >> > >> >> > Thanks, >> >> > Rafael >> >> >> >> No problem. >> >> >> >> The simulated suspend works fine. >> > >> > Good. >> > >> >> Also, waking up from S3 via a PS/2 keyboard works fine. >> > >> > Hmm. Do you mean that the USB3 controllers work after the resume if >> > the box has been woken up via the keyboard and they don't work when it >> > has been woken up via a power button? >> > >> > Rafael >> >> They work either way. I'm just not able to get the USB keyboard that >> is connected to the USB3 controller to perform the wakeup. (Which is >> what I thought I made clear from the beginning and what Alan Stern had >> reiterated for new readers further into the thread). > > Oh, I must have missed that information. Sorry about that. > > So, the situation is that if you set up the USB3 controllers to wake up > and next you wake up the system from S3 using a USB device connected to one > of those controllers, then they appear to be in D3 after the resume and > apparently cannot be put into D0. However, if the wakeup is done in any > different way, they work correctly after the resume, right? > > Is that the case on both the affected systems? > On both systems the USB3 controllers plugged into PCIe slots work fine after the system has been woken up from S3 suspend state. The USB3 keyboard plugged into the PCIe USB3 controller is immediately avaiable after the system has woken up. It is just that in Linux a keyboard plugged into the USB3 controller can not be used to wake the system up when it has gone into S3 suspend. With Windows 7 on our test systems our USB3 contoller (the Texas Instruments Inc. PCEe xHCI device) a USB keyboard plugged into it can wake it up from an S3 suspend. Dwight Schauer
On Wednesday, May 18, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 5:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Wednesday, May 18, 2011, Dwight Schauer wrote: > >> On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > On Tuesday, May 17, 2011, Dwight Schauer wrote: > >> >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > ... > >> >> > > >> >> > OK, one more test, please. > >> >> > > >> >> > Try to do > >> >> > > >> >> > # echo core > /sys/power/pm_test > >> >> > # echo mem > /sys/power/state > >> >> > > >> >> > (that should simulate suspend, but without going into the BIOS, and it > >> >> > should return do the command prompt after 5-10 sec.) and check if the > >> >> > USB3 controllers work after that ("echo none > /sys/power/pm_test" resets > >> >> > to the normal suspend behavior). > >> >> > > >> >> > Thanks, > >> >> > Rafael > >> >> > >> >> No problem. > >> >> > >> >> The simulated suspend works fine. > >> > > >> > Good. > >> > > >> >> Also, waking up from S3 via a PS/2 keyboard works fine. > >> > > >> > Hmm. Do you mean that the USB3 controllers work after the resume if > >> > the box has been woken up via the keyboard and they don't work when it > >> > has been woken up via a power button? > >> > > >> > Rafael > >> > >> They work either way. I'm just not able to get the USB keyboard that > >> is connected to the USB3 controller to perform the wakeup. (Which is > >> what I thought I made clear from the beginning and what Alan Stern had > >> reiterated for new readers further into the thread). > > > > Oh, I must have missed that information. Sorry about that. > > > > So, the situation is that if you set up the USB3 controllers to wake up > > and next you wake up the system from S3 using a USB device connected to one > > of those controllers, then they appear to be in D3 after the resume and > > apparently cannot be put into D0. However, if the wakeup is done in any > > different way, they work correctly after the resume, right? > > > > Is that the case on both the affected systems? > > > > On both systems the USB3 controllers plugged into PCIe slots work fine > after the system has been woken up from S3 suspend state. > > The USB3 keyboard plugged into the PCIe USB3 controller is immediately > avaiable after the system has woken up. It is just that in Linux a > keyboard plugged into the USB3 controller can not be used to wake the > system up when it has gone into S3 suspend. With Windows 7 on our test > systems our USB3 contoller (the Texas Instruments Inc. PCEe xHCI > device) a USB keyboard plugged into it can wake it up from an S3 > suspend. I see. It seems I'm confusing two different bug reports. :-( Sorry again. The runtime PM wakeup aside, what's the contents of /proc/acpi/wakeup before suspend (when you're going to try to wake up the system via USB)? Rafael
> -----Original Message----- > From: linux-usb-owner@vger.kernel.org [mailto:linux-usb- > owner@vger.kernel.org] On Behalf Of Dwight Schauer > Sent: Wednesday, May 18, 2011 7:02 AM > To: Rafael J. Wysocki > Cc: linux-pm@lists.linux-foundation.org; Sarah Sharp; dschauer@ti.com; > USB list > Subject: Re: [linux-pm] xHCI and suspend/resume > > On Tue, May 17, 2011 at 5:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Wednesday, May 18, 2011, Dwight Schauer wrote: > >> On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> > wrote: > >> > On Tuesday, May 17, 2011, Dwight Schauer wrote: > >> >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> > wrote: > >> > ... > >> >> > > >> >> > OK, one more test, please. > >> >> > > >> >> > Try to do > >> >> > > >> >> > # echo core > /sys/power/pm_test > >> >> > # echo mem > /sys/power/state > >> >> > > >> >> > (that should simulate suspend, but without going into the BIOS, > and it > >> >> > should return do the command prompt after 5-10 sec.) and check > if the > >> >> > USB3 controllers work after that ("echo none > > /sys/power/pm_test" resets > >> >> > to the normal suspend behavior). > >> >> > > >> >> > Thanks, > >> >> > Rafael > >> >> > >> >> No problem. > >> >> > >> >> The simulated suspend works fine. > >> > > >> > Good. > >> > > >> >> Also, waking up from S3 via a PS/2 keyboard works fine. > >> > > >> > Hmm. Do you mean that the USB3 controllers work after the resume > if > >> > the box has been woken up via the keyboard and they don't work > when it > >> > has been woken up via a power button? > >> > > >> > Rafael > >> > >> They work either way. I'm just not able to get the USB keyboard that > >> is connected to the USB3 controller to perform the wakeup. (Which is > >> what I thought I made clear from the beginning and what Alan Stern > had > >> reiterated for new readers further into the thread). > > > > Oh, I must have missed that information. Sorry about that. > > > > So, the situation is that if you set up the USB3 controllers to wake > up > > and next you wake up the system from S3 using a USB device connected > to one > > of those controllers, then they appear to be in D3 after the resume > and > > apparently cannot be put into D0. However, if the wakeup is done in > any > > different way, they work correctly after the resume, right? > > > > Is that the case on both the affected systems? > > > > On both systems the USB3 controllers plugged into PCIe slots work fine > after the system has been woken up from S3 suspend state. > > The USB3 keyboard plugged into the PCIe USB3 controller is immediately > avaiable after the system has woken up. It is just that in Linux a > keyboard plugged into the USB3 controller can not be used to wake the > system up when it has gone into S3 suspend. With Windows 7 on our test > systems our USB3 contoller (the Texas Instruments Inc. PCEe xHCI > device) a USB keyboard plugged into it can wake it up from an S3 > suspend. > I've verified that USB keyboard under xHCI controller can wakeup system from S3, either by press the keyboard or plug it in during suspend. But you need to enable wakeup in /proc/acpi/wakeup for the corresponding xHC controller. Thanks, Andiry
On Wednesday, May 18, 2011, Dwight Schauer wrote: > On Tue, May 17, 2011 at 8:59 PM, Xu, Andiry <Andiry.Xu@amd.com> wrote: > >> -----Original Message----- > >> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb- > >> owner@vger.kernel.org] On Behalf Of Dwight Schauer > >> Sent: Wednesday, May 18, 2011 7:02 AM > >> To: Rafael J. Wysocki > >> Cc: linux-pm@lists.linux-foundation.org; Sarah Sharp; dschauer@ti.com; > >> USB list > >> Subject: Re: [linux-pm] xHCI and suspend/resume > >> > >> On Tue, May 17, 2011 at 5:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > On Wednesday, May 18, 2011, Dwight Schauer wrote: > >> >> On Tue, May 17, 2011 at 4:54 PM, Rafael J. Wysocki <rjw@sisk.pl> > >> wrote: > >> >> > On Tuesday, May 17, 2011, Dwight Schauer wrote: > >> >> >> On Tue, May 17, 2011 at 4:43 PM, Rafael J. Wysocki <rjw@sisk.pl> > >> wrote: > >> >> > ... > >> >> >> > > >> >> >> > OK, one more test, please. > >> >> >> > > >> >> >> > Try to do > >> >> >> > > >> >> >> > # echo core > /sys/power/pm_test > >> >> >> > # echo mem > /sys/power/state > >> >> >> > > >> >> >> > (that should simulate suspend, but without going into the BIOS, > >> and it > >> >> >> > should return do the command prompt after 5-10 sec.) and check > >> if the > >> >> >> > USB3 controllers work after that ("echo none > > >> /sys/power/pm_test" resets > >> >> >> > to the normal suspend behavior). > >> >> >> > > >> >> >> > Thanks, > >> >> >> > Rafael > >> >> >> > >> >> >> No problem. > >> >> >> > >> >> >> The simulated suspend works fine. > >> >> > > >> >> > Good. > >> >> > > >> >> >> Also, waking up from S3 via a PS/2 keyboard works fine. > >> >> > > >> >> > Hmm. Do you mean that the USB3 controllers work after the resume > >> if > >> >> > the box has been woken up via the keyboard and they don't work > >> when it > >> >> > has been woken up via a power button? > >> >> > > >> >> > Rafael > >> >> > >> >> They work either way. I'm just not able to get the USB keyboard that > >> >> is connected to the USB3 controller to perform the wakeup. (Which is > >> >> what I thought I made clear from the beginning and what Alan Stern > >> had > >> >> reiterated for new readers further into the thread). > >> > > >> > Oh, I must have missed that information. Sorry about that. > >> > > >> > So, the situation is that if you set up the USB3 controllers to wake > >> up > >> > and next you wake up the system from S3 using a USB device connected > >> to one > >> > of those controllers, then they appear to be in D3 after the resume > >> and > >> > apparently cannot be put into D0. However, if the wakeup is done in > >> any > >> > different way, they work correctly after the resume, right? > >> > > >> > Is that the case on both the affected systems? > >> > > >> > >> On both systems the USB3 controllers plugged into PCIe slots work fine > >> after the system has been woken up from S3 suspend state. > >> > >> The USB3 keyboard plugged into the PCIe USB3 controller is immediately > >> avaiable after the system has woken up. It is just that in Linux a > >> keyboard plugged into the USB3 controller can not be used to wake the > >> system up when it has gone into S3 suspend. With Windows 7 on our test > >> systems our USB3 contoller (the Texas Instruments Inc. PCEe xHCI > >> device) a USB keyboard plugged into it can wake it up from an S3 > >> suspend. > >> > > > > I've verified that USB keyboard under xHCI controller can wakeup system > > from S3, either by press the keyboard or plug it in during suspend. But > > you need to enable wakeup in /proc/acpi/wakeup for the corresponding > > xHC controller. > > > > Thanks, > > Andiry > > I was told /proc/acpi/wakeup was deprecated, and to use > /sys/devices/pci.../power/wakeup instead. That is correct, but /proc/acpi/wakeup still contains valid information and is generally useful for debugging, so I'd appraciate it if you could tell me what's in there. > Anyways, the controllers in question are not showing up in > /proc/acpi/wakeup. These are add on cards, not devices included on the > motherboard. In that case you may try to enable wakeup for the bridges they are attached to. Hard to say without any more information. Thanks, Rafael
--- before.txt 2011-05-13 16:52:48.777129779 -0500 +++ after.txt 2011-05-13 16:52:48.777129779 -0500 @@ -615,17 +615,17 @@ 06:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Melco Inc Device 0241 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: Memory at fe9fe000 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) - Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME- + Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME+ Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=00001000 PBA: BAR=0 offset=00001080 Capabilities: [a0] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-