> -----Original Message----- > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd- > a...@freebsd.org] On Behalf Of Oliver Pinter > Sent: Saturday, December 3, 2016 1:11 PM > To: Hans Petter Selasky <hsela...@freebsd.org>; j...@freebsd.org > Cc: freebsd-acpi@freebsd.org; freebsd-am...@freebsd.org > Subject: Re: svn commit: r309400 - head/sys/dev/acpica > > On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter > <oliver.pin...@hardenedbsd.org> wrote: > > On 12/3/16, Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote: > >> On 12/3/16, Oliver Pinter <oliver.pin...@hardenedbsd.org> wrote: > >>> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky > >>> <hsela...@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: > > > > 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 > >> [Moore, Robert]
This is a regression in 20161117 that is fixed and will be released in about 2 weeks. Bob > >> but the lockup has gone. ;) > >> > > CC: ACPI and AMD64 > > >> > >> [trim] > >> _______________________________________________ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"