Garbled output from kgdb?

[Jung-uk Kim]

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(). :-)

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.
> >  */