From owner-freebsd-acpi@freebsd.org Sat Dec 3 20:56:38 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 5EEBBC652C0 for ; Sat, 3 Dec 2016 20:56:38 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::232]) (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 E8B031ADC for ; Sat, 3 Dec 2016 20:56:37 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wj0-x232.google.com with SMTP id qp4so259483779wjc.3 for ; Sat, 03 Dec 2016 12:56:37 -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=c9tgLfAwCsk+jZyVV08/glFWKvxX/XLm51SIL24rUQc=; b=08v7eieoDDdYgR0D9FxMMtk1u66dNDRXIO3RbuS0S52fKvYo8Jrq4+pgOxBZNLYmyM dbJerj1F360W43YE1KTl1PUt4O5bM39hT7PsW3tnKyB7rd98/3QXu6d5MG/jXTZCtgE4 kgfvCRc0edoh633xRpkL8emJ2NWYgign8Fbn5jdh8xy0nymcOdpbV82+DRADdxhKdRMW 7pIZ2Q19rRxNABHq7rYFphmiuCudDPjxVubJ5Vxn9QTo3ZeoWqzkD63cTA8Izsp4mwRi qyityhf6gSAhBlVqks+OI2CjPtB7Cr8X+3bDsj13QW6WzW3S/in6cJMOhwou0myXKEsS anDA== 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=c9tgLfAwCsk+jZyVV08/glFWKvxX/XLm51SIL24rUQc=; b=R4NDtHNiPx8XnGgL1UzQoxTmOlizgtvXTS9dA86e248zI/Jz8iQrkjR/Rf+AhBC94X WtLQcMFII3Rcvrh97s40E4a5SvYiL6F/sR9ZJ1MkpeWN98gjKv3T7T2tu38EbIEAtfTl ScuMWBShBRgM9vk4VFOtnxhGpq0VUK9WMp10x/cE/qfebv7VkxfOkUCYhdpzoo8bBhh+ T+gKC3iQuK3ix+Dn5lYDFLdZ2ENFRc9QegkemAPUbByV8hKKb4Wugfh7v2B6MW8wwMMK KFOD7tS51msZ1JluIwaDfqfljwmiE3UZxRmjI6GwrmW1bnw0bV3jMEzbPNqtTIbb9dF8 7kRQ== X-Gm-Message-State: AKaTC00dqH3A5XsxXO5fIT2mgOYxUtUPdLVGRhOVGhoUQsSZuaeQSGPjvPFq9CsJDvStLr1LfpmnoG5Hgl88RlVk X-Received: by 10.194.87.103 with SMTP id w7mr19891736wjz.164.1480798596207; Sat, 03 Dec 2016 12:56:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.253.65 with HTTP; Sat, 3 Dec 2016 12:56:35 -0800 (PST) In-Reply-To: References: <201612020821.uB28L8s2000195@repo.freebsd.org> From: Oliver Pinter Date: Sat, 3 Dec 2016 21:56:35 +0100 Message-ID: Subject: Re: svn commit: r309400 - head/sys/dev/acpica To: Hans Petter Selasky , jkim@freebsd.org Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , freebsd-acpi@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: Sat, 03 Dec 2016 20:56:38 -0000 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: [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]