From owner-freebsd-acpi@freebsd.org Tue Dec 6 22:48:17 2016 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49B36C692F4 for ; Tue, 6 Dec 2016 22:48:17 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0B501BFC for ; Tue, 6 Dec 2016 22:48:16 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wj0-x22a.google.com with SMTP id tg4so85197675wjb.1 for ; Tue, 06 Dec 2016 14:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xnCZLDWPpmofUmd7MkD57jZYTCkN/mdISt2DvhKkPl0=; b=XA62RzhvcDOrH/yj0Whc1oXUTdivqTIBzZy+8Zx8zOQR+lo8p+AuG0NHWtHez4et16 wb8EgdYsYJizOhHOnxl6maBYEoltUkGB/CH85QBtRThsK4M9peqRxczg1SgDfjUDrTxC ozQhmAz6k1TIYK53PsPGQ3IyPjnq9bnqwEZQl0cC0bw7l8IOfA94T453A0WKD4F5mZqW VvdOjoGZJV5b3AyZbv7/7LX2VaI/grF+WphQ1Ok2lycOoHRTYHQSCvgHXpGYAvZ0sf2I 7p8tlMzvGtnFpX0bxblQnOvLJ34IFoO5jAi9BhmKTPJdYqCVwlYTCdM0FK0tAP60v6ue dv2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xnCZLDWPpmofUmd7MkD57jZYTCkN/mdISt2DvhKkPl0=; b=aGyzEw4bYICeRFJGLea4tpSK2celTCHNktqSqr0c/bv4dcfUXq5qjrWu9Qhap0KECK zXVJNr+CjChNwsFiaagY3rGbK09rFrRmNfbDHUDWD2jkV/E/zXZO7SZFjrNuBNlcs2Bm EIlIcWJM/cZp4AP4VRDKiIdH0xtoz239zHphXRwxaT8lYIt5osP0m5hjp1YnzNxCBnxY fpT+7dGBWfhBAKHsMAF8eNUpj9jpZThSqJ8ldBBBJgTyaFYUMrRuNExifzJt7tqCAkKY Uh5LgNJ8jfmUGIuoIljfNM5ztuxl9fXa+b9e1rtbpxO7Bn+3/JJcJkHkF47SI0pw7nAd BhvA== X-Gm-Message-State: AKaTC01jnpS3qPrXXs7aVMbYTdMcIY5TuaVbFuVbmlMVzGoyygxyyLltCIbi0dJ8maLogZEapA22LOBrFz/dr6m9 X-Received: by 10.194.0.43 with SMTP id 11mr56773753wjb.218.1481064495236; Tue, 06 Dec 2016 14:48:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.253.65 with HTTP; Tue, 6 Dec 2016 14:48:14 -0800 (PST) In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E5370F4@ORSMSX110.amr.corp.intel.com> References: <201612020821.uB28L8s2000195@repo.freebsd.org> <94F2FBAB4432B54E8AACC7DFDE6C92E37E5370F4@ORSMSX110.amr.corp.intel.com> From: Oliver Pinter Date: Tue, 6 Dec 2016 23:48:14 +0100 Message-ID: Subject: Re: svn commit: r309400 - head/sys/dev/acpica To: "Moore, Robert" Cc: Hans Petter Selasky , "jkim@freebsd.org" , "freebsd-acpi@freebsd.org" , "freebsd-amd64@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:48:17 -0000 On Tue, Dec 6, 2016 at 11:01 PM, Moore, Robert wrote: > > >> -----Original Message----- >> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >> acpi@freebsd.org] On Behalf Of Oliver Pinter >> Sent: Saturday, December 3, 2016 1:11 PM >> To: Hans Petter Selasky ; jkim@freebsd.org >> Cc: freebsd-acpi@freebsd.org; freebsd-amd64@freebsd.org >> Subject: Re: svn commit: r309400 - head/sys/dev/acpica >> >> On Sat, Dec 3, 2016 at 9:58 PM, Oliver Pinter >> wrote: >> > On 12/3/16, Oliver Pinter wrote: >> >> On 12/3/16, Oliver Pinter wrote: >> >>> On Fri, Dec 2, 2016 at 9:21 AM, Hans Petter Selasky >> >>> 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: 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 Hi Bob, For me the original issue was different. Querying the acpi related sysctls locked up / deadlocked for me, and backporting the 20161117 ACPICA fixed the issue for me, but introduced a new one (probably the one what you mentioned). Btw, thanks for the info about the expected new release. Oliver > > > >> >> but the lockup has gone. ;) >> >> >> >> CC: ACPI and AMD64 >> >> >> >> >> [trim] >> >>