Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

On 2021-01-13 16:13, David Wolfskill wrote:
> On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote:
>> ...
>>> I believe that this is evidence in favor of a "race condition" diagnosis.
>>> (In precisely what, I don't know,)
>>
>> I haven't followed source changes too closely as of recent.
>> It might be a good idea to check for recent imports of ACPICA updates.
>> ....
> 
> Most recent of those in head was:
> 
> | commit fbde34778ba0ba31fcae99e992f353d989433dba
> | Merge: a2fe464c81de 960614968e0d
> | Author: Jung-uk Kim <jkim_at_FreeBSD.org>
> | Date:   Fri Nov 13 22:45:26 2020 +0000
> | 
> |     MFV:    r367652
> |     
> |     Merge ACPICA 20201113.
> | 
> | Notes:
> |     svn path=/head/; revision=367654
> 
> and I certainly had not been seeing the symptom at all until I
> mentioned it on 11 January.  (And I have been tracking head daily,
> including the "poweroff" at the end).

Another "wild" idea: some sort of a change related to signal delivery or
checking.

As I understand, the whole kernel shutdown procedure is executed in a
context of a userland process (init? shutdown?).  And I guess that that
process gets a signal at some point during the shutdown.
Now, our implementation of the ACPI mutex is such that it would abort /
fail if msleep(PCATCH) in it returns EINTR.  I was concerned about that
for a long time and I think that it is wrong, but it didn't cause much
problems before.  Also, I should note that that applies not only to
mutexes declared in AML but also to ACPICA's mutexes that protect its
internal states (such as ACPI_MTX_Caches / ACPI_MTX_CACHES which appears
in your output).

So, if that mutex is uncontested then it can be acquired even when a
signal is pending and everything is okay.  But if the mutex happens to
be held by some other thread, then the signal gets checked and the
operation is failed because of EINTR.

This is the only failure mode that I can think of for that mutex.
But again, I have no idea what could have changed recently with respect
to signal delivery / signal checking.
Or perhaps it's something else, something that creates concurrent ACPI
activity that increases likelihood of that mutex being contested.

-- 
Andriy Gapon