Garbled output from kgdb?

[Andriy Gapon]

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