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?
--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]
