On Sun, Apr 03, 2016 at 03:46:37PM -0700, patrick keshishian wrote: > digging in code now and I see that during wake, acpibtn_activate() > is called and it calls aml_evalinteger(..., "_LID", 0, NULL, &lid_open) > result of which indicates lid_open=1 (per ACPI spec non-zero means > lid is open); so yay. > > However, in the wake path in acpi_sleep_sate() acpibtn_numopenlids() > is called as follows: > > if (acpibtn_numopenlids() == 0 && lid_suspend != 0) > acpi_addtask(sc, acpi_sleep_task, sc, state); > > acpibtn_numopenlids() goes through acpibtn_lids list and similar > to acpibtn_activate() (mentioned above) calls > aml_evalinteger(..., "_LID", 0, NULL, &val) and counts number > of lids which return val != 0. > > For whatever reason, here, "_LID" returns 0 for the single lid > in this machine. > > I print the return values from both function calls into aml_evalinteger() > and both aml_evalnode() calls succeed, but the call from acpibtn_activate() > shows lid is open and the one from acpibtn_numopenlids() indicates > it is closed. > > In /var/log/messages, all the printf()s are within the same second. so > I am not sure if there is a race, where the latter executes first and > the status of _LID is still closed (not updated by ACPI?) and the former > gets executed slightly later and sees the updated state of _LID, but > syslog logs the messages out of order of actual execution? > > Ideas? >
Sounds like broken AML. I'd contact the machine vendor for an updated BIOS. The spec in section 9.4.1 clearly says _LID must always evaluate to the current state of the lid. If your lid is open, and the method evals to 0, it means either your AML is busted, or we have an error in our parser or other bug. If it were an error, I think we'd hear a lot of people screaming. The fact that it is only reported to be happening on one machine leads me to believe there is something wrong with this particular laptop. -ml > --patrick > > > On 4/2/16, patrick keshishian <[email protected]> wrote: > > maybe this helps. > > > > /var/log/messages with kernel built with ACPI_DEBUG (sources > > checked out roughly ~2016-03-30). > > > > Two wake attempts made far apart in time: 1st ~13:02 and the > > second ~13:14: > > [snip] >
