ACPI locking bugs?

[Jung-uk Kim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-02-27 09:54:53 -0500, Andriy Gapon wrote:
> 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; } }

When something is miserably waiting forever to grab a mutex/semaphore,
I wanted to be able to kill the misbehaving application, e.g., 'sysctl
- -a' from /etc/rc.d/initrandom.  Often times, it is caused by buggy DSDTs.

>> 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 suspect there's a bug in DSDT.

>> 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);

It should be fixed in ACPICA.  FYI, here is a patch to address the
problem:

https://github.com/otcshare/acpica/pull/5

IMHO, using ACPI_WAIT_FOREVER is really foot-shooting.  In fact, I
believe it should be removed from ACPI specification altogether.

>> 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?

Although I don't 100% agree with you, I decided to be more practical.
 Please try the attached patch.  It is also available from here:

http://people.freebsd.org/~jkim/OsdSynch.diff

I don't think it will fix anything, though.

Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBAgAGBQJRMRagAAoJECXpabHZMqHO+S8H/RnYNxLlLKM2u3s/VdRKXL1I
+WLgfdUpQoWU8RZvb9Kf7QzpiOsmEkEnUIiwYRkEos7YNUSObt8ivWsuxQx/Sxat
nzRl160HOHf9azgz9hlOfmWl1PLK12gMh/wX6E4WvYJLNQed5OXXlkqq9X4DSJ/Q
CVzxcLcKZYkoMFg1wvQcB1nSP4uGHkdtGQc0qB9WWNt4Gmb5T3wfLiy6T3j2YN3x
gchMhvJVTbbGTb5K1eZyahdacXpW3Ost2z/q/mB1eAjUwnsjF0Q95MzGInvIq3n6
wHizY8RHNDWfAyQMPAyqYFIPdbFjDHX6NFHQIIQw3ewn8fKylMi2npls7a9y51k=
=y21z
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OsdSynch.diff
Type: text/x-patch
Size: 8234 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20130301/5d0e6ff5/attachment.bin>