Date: Sat, 3 Dec 2016 21:56:35 +0100 From: Oliver Pinter <oliver.pinter@hardenedbsd.org> To: Hans Petter Selasky <hselasky@freebsd.org>, jkim@freebsd.org Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, freebsd-acpi@freebsd.org Subject: Re: svn commit: r309400 - head/sys/dev/acpica Message-ID: <CAPQ4fftNO3-kDh4BjYV0RBGDFftwtVUoyaeQse4aW9zennX1Bg@mail.gmail.com> In-Reply-To: <CAPQ4ffu38KhH2WkeV8H8uwX9BDKf_x2SuF36X-3cA4%2BJZ1XQWQ@mail.gmail.com> References: <201612020821.uB28L8s2000195@repo.freebsd.org> <CAPQ4ffu38KhH2WkeV8H8uwX9BDKf_x2SuF36X-3cA4%2BJZ1XQWQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/3/16, Oliver Pinter <oliver.pinter@hardenedbsd.org> wrote: > On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky > <hselasky@freebsd.org> wrote: >> Author: hselasky >> Date: Fri Dec 2 08:21:08 2016 >> New Revision: 309400 >> URL: https://svnweb.freebsd.org/changeset/base/309400 >> >> Log: >> Fix for endless recursion in the ACPI GPE handler during boot. >> >> When handling a GPE ACPI interrupt object the EcSpaceHandler() >> function can be called which checks the EC_EVENT_SCI bit and then >> recurse on the EcGpeQueryHandler() function. If there are multiple GPE >> events pending the EC_EVENT_SCI bit will be set at the next call to >> EcSpaceHandler() causing it to recurse again via the >> EcGpeQueryHandler() function. This leads to a slow never ending >> recursion during boot which prevents proper system startup, because >> the EC_EVENT_SCI bit never gets cleared in this scenario. >> >> The behaviour is reproducible with the ALASKA AMI in combination with >> a newer Skylake based mainboard in the following way: >> >> Enter BIOS and adjust the clock one hour forward. Save and exit the >> BIOS. System fails to boot due to the above mentioned bug in >> EcGpeQueryHandler() which was observed recursing multiple times. >> >> This patch adds a simple recursion guard to the EcGpeQueryHandler() >> function and also also adds logic to detect if new GPE events occurred >> during the execution of EcGpeQueryHandler() and then loop on this >> function instead of recursing. >> >> Reviewed by: jhb >> MFC after: 2 weeks >> >> Modified: >> head/sys/dev/acpica/acpi_ec.c > > > I have similar error since the latest BIOS update on my gigabyte > H170N-Wifi board. The curiosity of the BIOS update was after upgrading > to this version, there are no possibility to rollback to older > version. > > The other weird thing, is that MFCing back this patch does not help. I > get stucked lock in acmtx mutex, as you > could see from the attached log. The other interesting is the ACPI > error at boot time: > > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release > (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex > (20160527/exutils-147) > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release > (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex > (20160527/exutils-147) > [1] cpu1: <ACPI CPU> on acpi0 > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release > (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex > (20160527/exutils-147) > [1] ACPI Error: Mutex [0x0] is not acquired, cannot release > (20160527/utmutex-386) > [1] ACPI Error: Could not release AML Interpreter mutex > (20160527/exutils-147) > > (This error is on 10-STABLE.) > After backported the last to ACPICA update to 10-STABLE with this patch, the issue reducated to this warning message: [1] acpi0: Power Button (fixed) [1] ACPI Error: Method parse/execution failed [\134_SB.PCI0.IOTR._CRS] (Node 0xfffff80006592f00), AE_AML_NO_RESOURCE_END_TAG (20161117/psparse-560) [1] ACPI Error: Method execution failed [\134_SB.PCI0.IOTR._CRS] (Node 0xfffff80006592f00), AE_AML_NO_RESOURCE_END_TAG (20161117/uteval-111) [1] can't fetch resources for \134_SB_.PCI0.IOTR - AE_AML_NO_RESOURCE_END_TAG but the lockup has gone. ;) [trim]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4fftNO3-kDh4BjYV0RBGDFftwtVUoyaeQse4aW9zennX1Bg>