Garbled output from kgdb?
Andriy Gapon
avg at icyb.net.ua
Tue May 5 16:51:43 UTC 2009
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
More information about the freebsd-stable
mailing list