From owner-freebsd-current@freebsd.org Wed Jan 13 17:01:35 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 788A74E2688 for ; Wed, 13 Jan 2021 17:01:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DGDHg1qCVz3CRy for ; Wed, 13 Jan 2021 17:01:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3CAB04E234E; Wed, 13 Jan 2021 17:01:35 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C5714E276D for ; Wed, 13 Jan 2021 17:01:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGDHf5wlfz3CGV; Wed, 13 Jan 2021 17:01:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 195.64.148.76 Received: from [192.168.0.24] (unknown [195.64.148.76]) (Authenticated sender: andriy.gapon@uabsd.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id EB9DD40002; Wed, 13 Jan 2021 17:01:31 +0000 (UTC) Subject: Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850 To: David Wolfskill , current@freebsd.org References: <7bbd01c4-abfe-f046-a35e-79fc60f7cf66@FreeBSD.org> From: Andriy Gapon Cc: Jung-uk Kim Message-ID: <4ab1d382-42e2-5a4f-3c58-10d26c5e9709@FreeBSD.org> Date: Wed, 13 Jan 2021 19:01:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DGDHf5wlfz3CGV X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 17:01:35 -0000 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 > | 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