svn commit: r309400 - head/sys/dev/acpica
Oliver Pinter
oliver.pinter at hardenedbsd.org
Sat Dec 3 20:56:38 UTC 2016
On 12/3/16, Oliver Pinter <oliver.pinter at hardenedbsd.org> wrote:
> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky
> <hselasky at 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]
More information about the svn-src-all
mailing list