On Wed, Jul 30, 2014 at 11:07:27AM -0400, Elijah Buck wrote: > On Wed, Jul 30, 2014 at 01:26:06AM -0700, Mike Larkin wrote: > > I've got a machine with the same symptoms with very similar hardware. > > It doesn't fire any GPEs on resume, and the fixed function buttons aren't > > set either. So the reason for resume is still a mystery. > > > > 1. Please send an acpidump. > > > > 2. In dev/acpi/acpi.c, try commenting out the following line: > > > > acpi_enable_wakegpes(sc, state); > > > > ... in my tree that's on line 2157. Note there are two occurrences of that > > line of code, you want to comment out the one in acpi_sleep_state and not > > acpi_powerdown. Then rebuild/reinstall the kernel and see if ZZZ works - > > that change will disable the wake devices > > > > -ml > > The change to dev/acpi/acpi.c works perfectly.
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 > > I am attaching a tar of the apcidump output (which will of course be > stripped by the list). Let me know if there's another way you'd like me > to send it. > > Thanks, > Elijah > > [demime 1.01d removed an attachment of type application/x-tar]
