Date: Thu, 21 Mar 2013 16:43:51 +0000 From: "Moore, Robert" <robert.moore@intel.com> To: Jung-uk Kim <jkim@FreeBSD.org>, Hans Petter Selasky <hps@bitfrost.no> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: RE: ACPI locking bugs? Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F48ADF4@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Update on ACPICA mutex use, added to the ACPICA reference:
4.3.2.1 Internal use of Mutex Objects
ACPICA defines the following mutex objects for internal use:
Interpreter: Lock for the entire AML interpreter
Namespace: Lock for the internal ACPI namespace data structure
Tables: Lock for the ACPI tables received from the BIOS
Caches: General lock for internal caches
Memory: Lock for the debug-only memory tracking list(s)
Debug Command Complete: Synchroniziation for the AML debugger
Debug Command Ready: Synchroniziation for the AML debugger
When using these mutex objects, ACPICA obeys the following rules:
1) Mutex objects are always acquired in the order of the objects defined ab=
ove. For example, if the Tables lock has been acquired, the Namespace or In=
terpreter lock will never be subsequently acquired .=20
2) However, the acquisition of a mutex does not imply or require that previ=
ous mutex objects must be acquired. In other words, the Namespace lock may =
be acquired without holding the Interpreter lock.
3) Mutex objects are never acquired recursively by ACPICA.
4) Mutex objects are always released in the reverse of the acquisition orde=
r.
5) The ACPI_MUTEX_DEBUG compile-time option may be specified that will enab=
le code that checks for and enforces the rules above. This option is typica=
lly used to debug the ACPICA code and ensure that the rules above are stric=
tly adhered to.
These rules of use are published here in order to help developers implement=
the mutex objects within the host OSL.
NOTE: These rules do not apply directly to the ASL/AML Mutex object, which =
has slightly different rules as defined by the ACPI specification.
> -----Original Message-----
> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd-
> acpi@freebsd.org] On Behalf Of Moore, Robert
> Sent: Wednesday, February 27, 2013 12:34 PM
> To: Jung-uk Kim; Hans Petter Selasky
> Cc: freebsd-acpi@freebsd.org
> Subject: RE: ACPI locking bugs?
>=20
> A couple comments below.
>=20
> > -----Original Message-----
> > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd-
> > acpi@freebsd.org] On Behalf Of Jung-uk Kim
> > Sent: Wednesday, February 27, 2013 11:28 AM
> > To: Hans Petter Selasky
> > Cc: freebsd-acpi@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 =3D AE_TIME; break; case ACPI_WAIT_FOREVER: while
> > > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =3D
> > > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error
> > > =3D=3D EINTR || as->as_reset) { status =3D AE_ERROR; break; } } break=
;
> > > default: tmo =3D timeout2hz(Timeout); while (!ACPISEM_AVAIL(as,
> > > Units)) { prevtick =3D ticks; as->as_waiters++; error =3D
> > > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--;
> > > if (error =3D=3D EINTR || as->as_reset) { status =3D AE_ERROR; break;=
} if
> > > (ACPISEM_AVAIL(as, Units)) break; slptick =3D ticks - prevtick; if
> > > (slptick >=3D tmo || slptick < 0) { status =3D AE_TIME; break; } tmo =
-=3D
> > > 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
>=20
> >
> > 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.
>=20
>=20
> 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.
>=20
>=20
> >
> > 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]
> >
>=20
> 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.)
>=20
>=20
>=20
>=20
> > 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=3D
> > =3Do9HQ
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > freebsd-acpi@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94F2FBAB4432B54E8AACC7DFDE6C92E36F48ADF4>