Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 May 2009 16:23:30 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Jung-uk Kim <jkim@FreeBSD.org>
Cc:        Alan Amesbury <amesbury@umn.edu>, freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon <avg@icyb.net.ua>
Subject:   Re: Garbled output from kgdb?
Message-ID:  <4A00A042.20806@FreeBSD.org>
In-Reply-To: <200905051609.38689.jkim@FreeBSD.org>
References:  <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A00A042.20806>