From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 5 12:04:53 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 05F003C0; Wed, 5 Dec 2012 12:04:53 +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 127378FC16; Wed, 5 Dec 2012 12:04:51 +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 OAA13323; Wed, 05 Dec 2012 14:04: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 1TgAvC-0009x9-8t; Wed, 05 Dec 2012 11:05:38 +0200 Message-ID: <50BF0E60.30705@FreeBSD.org> Date: Wed, 05 Dec 2012 11:05:36 +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> In-Reply-To: <20121204085000.GA1445@mole.fafoe.narf.at> 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: Wed, 05 Dec 2012 12:04:53 -0000 on 04/12/2012 10:50 Stefan Farfeleder said the following: > These checks have not triggered additional panics. I still get the cycle > one. I am really out of ideas now on how that cycle could be created... :-( Perhaps, try to add another copy of the loop detection code to the place after an object is added to the cache list and before the mutex is released. And also, just in case, another copy to AcpiOsAcquireObject. -- Andriy Gapon