From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 19:25:47 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 0B18F361; Sun, 23 Dec 2012 19:25:47 +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 F1B158FC12; Sun, 23 Dec 2012 19:25:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA25838; Sun, 23 Dec 2012 21:25:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmrB9-000FyV-Mv; Sun, 23 Dec 2012 21:25:43 +0200 Message-ID: <50D75AB5.1040803@FreeBSD.org> Date: Sun, 23 Dec 2012 21:25:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121125140008.GA1497@mole.fafoe.narf.at> <50B244A1.1040800@FreeBSD.org> <20121126091101.GA1469@mole.fafoe.narf.at> <50B33693.2060000@FreeBSD.org> <20121126093704.GB1469@mole.fafoe.narf.at> <50B34484.1090807@FreeBSD.org> <20121126104737.GC1469@mole.fafoe.narf.at> <50B34EEA.4000209@FreeBSD.org> <20121129084627.GA1450@mole.fafoe.narf.at> <50B7D717.4030402@FreeBSD.org> <20121204085000.GA1445@mole.fafoe.narf.at> <50BF0E60.30705@FreeBSD.org> In-Reply-To: <50BF0E60.30705@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 23 Dec 2012 19:25:47 -0000 Stefan, long time, no news... So, I decided to attempt a different approach to the problem. Could you please try the following patch if you are still experiencing the problem? Could you please report how it goes? My hope is that, even if the problem persist, it will be easier to debug it using FreeBSD built-in debugging capabilities like INVARIANTS, WITNESS, DEBUG_MEMGUARD, etc. commit 12a6b3610b82e5370bf32f3c3ea5ac1fae46bb63 Author: Andriy Gapon Date: Sun Dec 23 19:52:26 2012 +0200 [test] acpi: use uma instead of acpica internal object cache implementation diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h b/sys/contrib/dev/acpica/include/platform/acfreebsd.h index d7aa7ed..2f2abd6 100644 --- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h +++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h @@ -54,7 +54,6 @@ #define ACPI_UINTPTR_T uintptr_t #define ACPI_USE_DO_WHILE_0 -#define ACPI_USE_LOCAL_CACHE #define ACPI_USE_SYSTEM_CLIBRARY #ifdef _KERNEL @@ -64,9 +63,11 @@ #include #include #include +#include #include "opt_acpi.h" +#define ACPI_CACHE_T struct uma_zone #define ACPI_MUTEX_TYPE ACPI_OSL_MUTEX #ifdef ACPI_DEBUG diff --git a/sys/dev/acpica/Osd/OsdMemory.c b/sys/dev/acpica/Osd/OsdMemory.c index b806642..5108f04 100644 --- a/sys/dev/acpica/Osd/OsdMemory.c +++ b/sys/dev/acpica/Osd/OsdMemory.c @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include static MALLOC_DEFINE(M_ACPICA, "acpica", "ACPI CA memory pool"); @@ -143,3 +144,39 @@ AcpiOsWriteMemory(ACPI_PHYSICAL_ADDRESS Address, UINT64 Value, UINT32 Width) return (AE_OK); } + +ACPI_STATUS +AcpiOsCreateCache(char *CacheName, UINT16 ObjectSize, UINT16 MaxDepth, + ACPI_CACHE_T **ReturnCache) +{ + *ReturnCache = uma_zcreate(CacheName, ObjectSize, NULL, NULL, NULL, NULL, + UMA_ALIGN_PTR, 0); + return (AE_OK); +} + +ACPI_STATUS +AcpiOsDeleteCache(ACPI_CACHE_T *Cache) +{ + uma_zdestroy(Cache); + return (AE_OK); +} + +ACPI_STATUS +AcpiOsPurgeCache(ACPI_CACHE_T *Cache) +{ + zone_drain(Cache); + return (AE_OK); +} + +void * +AcpiOsAcquireObject(ACPI_CACHE_T *Cache) +{ + return uma_zalloc(Cache, M_ZERO | M_WAITOK); +} + +ACPI_STATUS +AcpiOsReleaseObject(ACPI_CACHE_T *Cache, void *Object) +{ + uma_zfree(Cache, Object); + return (AE_OK); +} -- Andriy Gapon