From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 9 13:46:07 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6B9471D for ; Fri, 9 Nov 2012 13:46:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CEE408FC12 for ; Fri, 9 Nov 2012 13:46:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA26923; Fri, 09 Nov 2012 15:46:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <509D091A.8080108@FreeBSD.org> Date: Fri, 09 Nov 2012 15:46:02 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource] References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> <509B8F15.4030300@FreeBSD.org> <509BDF86.3080502@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:46:07 -0000 on 09/11/2012 14:17 Tom Lislegaard said the following: > kgdb) up 7 > #7 0xffffffff802d1bdd in AcpiOsAcquireObject (Cache=0xfffffe00052bac60) at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:316 > 316 ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, > (kgdb) x/9a Cache->ListHead > 0xfffffffeec85c730: Cannot access memory at address 0xfffffffeec85c730 [Slaps forehead] Ah, right, indeed. I guess the problem hasn't happened again since then? Does the patch appear to work OK so far (with respect to the original problem)? I have a suspicion about what causes the new problem. If it is correct then the following experimental patch may help with it: --- a/sys/contrib/dev/acpica/components/utilities/utdelete.c +++ b/sys/contrib/dev/acpica/components/utilities/utdelete.c @@ -415,6 +415,8 @@ AcpiUtUpdateRefCount ( return; } + (void) AcpiUtAcquireMutex (ACPI_MTX_REFCOUNTS); + Count = Object->Common.ReferenceCount; NewCount = Count; @@ -490,6 +492,8 @@ AcpiUtUpdateRefCount ( ACPI_WARNING ((AE_INFO, "Large Reference Count (0x%X) in object %p", Count, Object)); } + + (void) AcpiUtReleaseMutex (ACPI_MTX_REFCOUNTS); } --- a/sys/contrib/dev/acpica/include/aclocal.h +++ b/sys/contrib/dev/acpica/include/aclocal.h @@ -89,8 +89,9 @@ union acpi_parse_object; #define ACPI_MTX_MEMORY 5 /* Debug memory tracking lists */ #define ACPI_MTX_DEBUG_CMD_COMPLETE 6 /* AML debugger */ #define ACPI_MTX_DEBUG_CMD_READY 7 /* AML debugger */ +#define ACPI_MTX_REFCOUNTS 8 /* ACPI object reference counts */ -#define ACPI_MAX_MUTEX 7 +#define ACPI_MAX_MUTEX 8 #define ACPI_NUM_MUTEX ACPI_MAX_MUTEX+1 -- Andriy Gapon