Garbled output from kgdb?

[Andriy Gapon]

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