From owner-freebsd-acpi@FreeBSD.ORG Tue May 5 20:23:30 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 5A1461065673; Tue, 5 May 2009 20:23:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE368FC08; Tue, 5 May 2009 20:23:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C153F46B09; Tue, 5 May 2009 16:23:29 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [127.0.0.1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 24E518A022; Tue, 5 May 2009 16:23:28 -0400 (EDT) Message-ID: <4A00A042.20806@FreeBSD.org> Date: Tue, 05 May 2009 16:23:30 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jung-uk Kim References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 05 May 2009 16:23:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon 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 20:23:31 -0000 Jung-uk Kim wrote: > 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(). :-) I'm not sure all ACPI locks need to be spin locks, but any locks used by the idle code must be spin locks. Regardless, are you going to import a newer ACPI-CA and commit your patches soon? It sounds like several things are fixed in the outstanding patches by now including both this and the problem with the Alias() operator. > 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. >>> */ -- John Baldwin