ACPI locking bugs?
Hans Petter Selasky
hps at bitfrost.no
Wed Feb 27 13:52:35 UTC 2013
Hi,
What is the reason for using cv_wait_sig() and cv_timedwait_sig() instead of
cv_wait() and cv_timedwait() inside of AcpiOsWaitSemaphore(). What signals are
supposed to be catched here?
switch (Timeout) {
case ACPI_DO_NOT_WAIT:
if (!ACPISEM_AVAIL(as, Units))
status = AE_TIME;
break;
case ACPI_WAIT_FOREVER:
while (!ACPISEM_AVAIL(as, Units)) {
as->as_waiters++;
error = cv_wait_sig(&as->as_cv, &as->as_lock);
as->as_waiters--;
if (error == EINTR || as->as_reset) {
status = AE_ERROR;
break;
}
}
break;
default:
tmo = timeout2hz(Timeout);
while (!ACPISEM_AVAIL(as, Units)) {
prevtick = ticks;
as->as_waiters++;
error = cv_timedwait_sig(&as->as_cv, &as->as_lock,
tmo);
as->as_waiters--;
if (error == EINTR || as->as_reset) {
status = AE_ERROR;
break;
}
if (ACPISEM_AVAIL(as, Units))
break;
slptick = ticks - prevtick;
if (slptick >= tmo || slptick < 0) {
status = AE_TIME;
break;
}
tmo -= slptick;
}
}
I've observed an issue twice on my MacBookPro that some ACPI locking fails
during shutdown on 9-stable and then the power-off won't complete. I've been
unable to capture the full dmesg, because syslogd is killed at the moment this
happens. There are two ACPI error printouts about failed locking.
I see that in the case of ACPI_WAIT_FOREVER, it appears to be incorrect to
catch signals, because sometimes the return argument is not checked for lock
operations:
./components/utilities/utosi.c: (void) AcpiOsAcquireMutex
(AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
./components/utilities/utosi.c: (void) AcpiOsAcquireMutex
(AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
./components/utilities/utosi.c: (void) AcpiOsAcquireMutex
(AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
Any comments?
Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore
--HPS
More information about the freebsd-acpi
mailing list