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 <j...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"