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? > > 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. Alan Stern -- 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
