Wed, Jul 30, 2014 at 12:29:00PM -0700, Mike Larkin wrote: > That's good news, but unfortunately it's just a diagnostic tool to indicate > what I already suspected - a GPE is firing, but it's still unknown which one. > The spec is a little unclear here (gee, what a surprise). It only says that > the implementation must provide "a way" for OSPM to determine the GPE that > fired to wake the machine up. But it doesn't say what "that way" is. A few > weeks ago I cooked up a diff to read the GPE status right on wake (from S3) > and on the machines I have that immediately wake from S3, it didn't show any > GPE as signaled. We can't use the same approach on wake from S4 because of > all the other stuff that happens before we can read the GPE registers. > > The change I recommended can't be committed as is. But it does help point > things in the right direction. I'll take a look at the AML and see if I can > see a suspect GPE. > > -ml >
Is it possible to disable individual wakeup devices? (acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) [...]). Would that help track down where the GPE is coming from? Elijah
