ACPI locking bugs?

[Moore, Robert]

A couple comments below.

> -----Original Message-----
> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
> acpi at freebsd.org] On Behalf Of Jung-uk Kim
> Sent: Wednesday, February 27, 2013 11:28 AM
> To: Hans Petter Selasky
> Cc: freebsd-acpi at freebsd.org
> Subject: Re: ACPI locking bugs?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote:
> > 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
> 
> I don't exactly remember why it was written like that, sorry.
> Probably it was to work around broken mutex uses in ACPICA at the time.
> 
> FYI, many ACPICA patches are contributed by Linux developers.
> Unfortunately, the Linux OS-dependent code does not implement the ACPICA
> OSL API fully and omits some corner cases. [1]
> 
> For example, ACPICA mutex is implemented via semaphore:
> 
> http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51
> http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239
> 
> And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER:
> 
> http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227

> 
> So, a lot of locking related ACPICA patches ignored these corner cases.
> Another problem is that we are very serious about locking orders but
> ACPICA doesn't really care much because Linux and others don't care,
> really.


I believe that ACPICA does in fact worry about locking order. We have an ordered list of the mutex objects that are used internally, and at least in debug mode, it checks to make sure that the ordering is correct, for both acquire and release.


> 
> Another example is the ACPICA "cache" allocator.  It is actually modeled
> after Linux's slab allocator, i.e., kmem_cache_*():
> 
> http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636
> 
> Unfortunately, it doesn't really fit into our closest KPI, i.e., zone(9).
> [2]
> 

You can, of course do one of these:
    1) Use the default ACPICA cache allocator
    2) Configure ACPICA to just not use any caching (if your memory allocator will suffice.)




> We always tried our best to *fully* implement OSL but it is not an easy
> task. :-(
> 
> Jung-uk Kim
> 
> 1.  For the official ACPICA OS-dependent API, please see "ACPI Component
> Architecture User Guide and Programmer Reference".  You can get it from
> here:
> 
> https://www.acpica.org/documentation/
> 
> 2.  There were some patches but I am not really comfortable with any of
> these patches yet.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (FreeBSD)
> 
> iQEcBAEBAgAGBQJRLl5MAAoJECXpabHZMqHOyi0IAMbzAggbm+XRlVeSFaEtZpvc
> 6VyceBmTh/OBgO8rdUEXbWuY/CpyQixYBlKIowDa+vJrzhAbA1louywWRvLXlfCc
> sbw6yGsX8gMbucU648duTDTePw80JxMLs/Rl7aSXm4Rq+wVNRlnBzs/pOrLjdhfU
> 0ChK+atphQED9DKNfa7aYAlkANaQ6pDgI03E8Te8Bu5zeflaaSpj2rE7VLlXH/kK
> XBbO+83Tsy7/gBdWqdTXtVP2FQQvg39M932ZeD0qFaefd25R9yVr6UppqIF4BtIO
> dq9yavmZbkmkM9bstWPdu6D8pV9UlsbyAk6dseXNwpiL1adkacAsigwcXoSa6mE=
> =o9HQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"