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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
