ACPI locking bugs?

Andriy Gapon avg at FreeBSD.org
Wed Feb 27 14:55:00 UTC 2013


on 27/02/2013 15:53 Hans Petter Selasky said the following:
> 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?

kib drew my attention to this issue some time ago and I also pinged jkim about it.
I completely agree with you that the signal handling should be removed.
Are you willing to make the change or would you prefer me doing it?

Thank you.

-- 
Andriy Gapon


More information about the freebsd-acpi mailing list