svn commit: r309400 - head/sys/dev/acpica

Moore, Robert robert.moore at intel.com
Tue Dec 6 22:03:05 UTC 2016



> -----Original Message-----
> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
> acpi at freebsd.org] On Behalf Of Oliver Pinter
> Sent: Saturday, December 3, 2016 1:11 PM
> To: Hans Petter Selasky <hselasky at freebsd.org>; jkim at freebsd.org
> Cc: freebsd-acpi at freebsd.org; freebsd-amd64 at freebsd.org
> Subject: Re: svn commit: r309400 - head/sys/dev/acpica
> 
> On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter
> <oliver.pinter at hardenedbsd.org> wrote:
> > On 12/3/16, Oliver Pinter <oliver.pinter at hardenedbsd.org> wrote:
> >> 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:
> >
> > 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]
> >>


More information about the freebsd-amd64 mailing list