No, see below.
> A non-preempt kernel will not increment preempt_count() when
> it takes a spinlock and ACPI could mistakenly schedule away
> and cause a system deadlock.
acpi_enter_sleep_state should not be acquiring any semaphores. All calls
to acpi_set_register in that function should be called with
ACPI_MTX_DO_NOT_LOCK. Problem solved. :)
Andrew, as to why we are doing this:
The main function of the ACPI interpreter is to execute control methods.
We never execute a control method from an interrupt, we always do it
from thread context. We have semaphores to protect various resources,
and use this function (acpi_os_wait_semaphore) to acquire them. We
usually call it with timeout value ACPI_WAIT_FOREVER, which results in a
down().
However, we also have to execute control methods early in the boot
sequence. down() would never block but it thinks it might, so we want to
call down_trylock instead. in_atomic() seemed to be a good (?) way to
tell whether we need to avoid down() or not.
Thoughts on better ways to do this, perhaps? I guess I should at least
add a comment above that line.
Regards -- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/