On 4/4/16, Mike Larkin <[email protected]> wrote: > 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.
Thanks for your reply Mike. I will look for a BIOS update. Last time I looked there were none. This laptop came with some version of Windows (I forget now which), it had no issues with sleep/wake/hibernate/etc. Assuming the issue is with broken AML and the BIOS, then Windows must have known about the exact bugs and had workarounds. Is this how things work? --patrick > -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] >> >
