On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter <[email protected]> wrote: > On 12/3/16, Oliver Pinter <[email protected]> wrote: >> On 12/3/16, Oliver Pinter <[email protected]> wrote: >>> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky >>> <[email protected]> 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: > > Attached the two backport. > >> >> [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. ;) >>
CC: ACPI and AMD64 >> >> [trim] >>
0001-HBSD-MFC-pull-in-ACPICA-20160930-from-FreeBSD-12-CUR.patch.xz
Description: Binary data
0002-HBSD-MFC-Merge-ACPICA-20161117.patch.xz
Description: Binary data
_______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "[email protected]"
