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 _______________________________________________ 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"
