From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 16:45:48 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F93106566B; Tue, 5 May 2009 16:45:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DAD2A8FC0A; Tue, 5 May 2009 16:45:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 TAA23083; Tue, 05 May 2009 19:45:44 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006D38.50901@icyb.net.ua> Date: Tue, 05 May 2009 19:45:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> In-Reply-To: <200905011501.40083.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:45:48 -0000 on 01/05/2009 22:01 John Baldwin said the following: > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it is > a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks > protecting the idle registers need to use spin locks instead. The problem with > blocking in the idle thread is that the scheduler assumes (even requires) that > the idle thread is _always_ runnable. Very interesting! So it seems that we are not having more of such crashes by a pure luck (low probability)? Looking at the method's signature: ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) I think that the name of the parameter type is a big hint. Further, looking into ACPICA reference document: > Wait for and acquire a spin lock. May be called from interrupt handlers, GPE > handlers, and Fixed event handlers. Single threaded OSL implementations should > always return AE_OK for this interface. P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be outdated/bogus too - first of all there is no Flags parameter (it's actualy a return value "to be used when lock is released") and, second, having ithreads is no excuse to not care about type of blocking, and the term 'blocking' is used incorrectly too: /* * The Flags parameter seems to state whether or not caller is an ISR * (and thus can't block) but since we have ithreads, we don't worry * about potentially blocking. */ -- Andriy Gapon