From owner-freebsd-stable@FreeBSD.ORG Tue May 5 20:09:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A88981065676; Tue, 5 May 2009 20:09:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Tue, 5 May 2009 16:09:35 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> In-Reply-To: <4A006E9A.7060806@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905051609.38689.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, John Baldwin 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 20:09:47 -0000 On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > 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. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) Jung-uk Kim > 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. > > */