From owner-freebsd-stable@FreeBSD.ORG Tue May 5 16:51:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6569C106564A; Tue, 5 May 2009 16:51:42 +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 058598FC1E; Tue, 5 May 2009 16:51:40 +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 TAA23148; Tue, 05 May 2009 19:51:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A006E9A.7060806@icyb.net.ua> Date: Tue, 05 May 2009 19:51:38 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: John Baldwin , Jung-uk Kim References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> <4A006D38.50901@icyb.net.ua> In-Reply-To: <4A006D38.50901@icyb.net.ua> 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-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:51:43 -0000 BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. on 05/05/2009 19:45 Andriy Gapon said the following: > 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