On Wednesday, September 28, 2011, Alan Stern wrote: > On Tue, 27 Sep 2011, Rafael J. Wysocki wrote: > > > > > What's there in /proc/acpi/wakeup ? > > > > > > Here it is: > > > > > > Device S-state Status Sysfs node > > > P0P4 S4 *disabled pci:0000:00:1e.0 > > > MC97 S4 *disabled > > > USB1 S4 *enabled pci:0000:00:1d.0 > > > USB2 S4 *enabled pci:0000:00:1d.1 > > > USB3 S4 *enabled pci:0000:00:1d.2 > > > USB4 S4 *enabled pci:0000:00:1d.3 > > > EUSB S4 *enabled pci:0000:00:1d.7 > > > PS2K S4 *enabled pnp:00:09 > > > PS2M S4 *disabled pnp:00:0a > > > GBEN S4 *disabled > > > > > > Of course the 000:01:01.1 device isn't on the list, because it's part > > > of an add-on PCI card, not built into the motherboard. > > > > > > I tried echoing "P0P4" to /proc/acpi/wakeup, which caused the first > > > line above to say "enabled", but there was no difference in behavior. > > > Is the fact that the S-state column says S4 relevant (bearing in mind > > > that the test does an S3 suspend)? > > > > > > I also checked the setting of > > > /sys/bus/pci/devices/0000:00:1e.0/power/wakeup, and it says "enabled" > > > following the write to /proc/acpi/wakeup. > > > > That's how it is supposed to work. > > > > > Now, it's possible that the problem is at a lower level. Maybe the > > > device is not getting wakeup power even though it's supposed to be in > > > D3hot. > > > > That's possible. Moreover, it is possible that the BIOS removes power > > from the bus segment the device is on entirely, in which case it would > > need the auxiliary power source to generate wakeup events. > > Is there any way to find out whether this is happening? Frankly, I don't know. We may be entering an area that's never been tested by any vendors in this case. > > > I don't know how to check that, however, or how to see whether > > > or not its PME# signal is asserted when the system wakes up. By the > > > time the system finishes resuming it is too late, because the driver's > > > resume routine does a complete reset of the device (not to mention that > > > the PCI subsystem's resume routine restores the device's config space > > > contents and disables PME#). > > > > Hmm. Does the device report being able to generate wakeup events from D3_cold? > > # lspci -vv -s 1:01.01 > 01:01.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) > Subsystem: NEC Corporation Hama USB 2.0 CardBus > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 32 (250ns min, 10500ns max), Cache Line Size: 32 bytes > Interrupt: pin B routed to IRQ 23 > Region 0: Memory at fe5de000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Kernel driver in use: ohci_hcd > Kernel modules: ohci-hcd > > Apparently not. So it won't generate PMEs if the bus segment is powered down during system suspend. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
