On Tuesday, September 27, 2011, Alan Stern wrote: > On Mon, 26 Sep 2011, Rafael J. Wysocki wrote: > > > > The test results are as follows. During late suspend: > > > > > > acpi_pci_sleep_wake() is called for the 0000:01:01.1 device > > > with enable set to 1. > > > > > > acpi_pci_can_wakeup() returns 0. > > > > > > acpi_pci_propagate_wakeup_enable() is called for the 0000:01 > > > bus device, also known as 0000:00:1e.0. > > > > > > acpi_pm_device_sleep_wake() is called for 0000:00:1e.0; it > > > prints out "pci 0000:00:1e.0: wake-up capability enabled by > > > ACPI" and returns 0. > > > > > > This causes acpi_pci_propagate_wakeup_enable() to return from > > > within the "while (bus->parent)" loop. > > > > > > There also are log messages stating "ohci_hcd 0000:01:01.1: PME# > > > enabled" and "ohci_hcd 0000:01:01.1: --> PCI D3hot". Nevertheless, it > > > doesn't wake up the system. > > > > 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. > 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? 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
