Date: Wed, 27 Feb 2013 20:33:53 +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: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> In-Reply-To: <512E5E4C.807@FreeBSD.org> References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
A couple comments below.
> -----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?
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> 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
>=20
> 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.
>=20
> 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]
>=20
> For example, ACPICA mutex is implemented via semaphore:
>=20
> 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
>=20
> And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER:
>=20
> 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.
I believe that ACPICA does in fact worry about locking order. We have an or=
dered list of the mutex objects that are used internally, and at least in d=
ebug mode, it checks to make sure that the ordering is correct, for both ac=
quire and release.
>=20
> Another example is the ACPICA "cache" allocator. It is actually modeled
> after Linux's slab allocator, i.e., kmem_cache_*():
>=20
> http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636
>=20
> 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 allocat=
or will suffice.)
> We always tried our best to *fully* implement OSL but it is not an easy
> task. :-(
>=20
> Jung-uk Kim
>=20
> 1. For the official ACPICA OS-dependent API, please see "ACPI Component
> Architecture User Guide and Programmer Reference". You can get it from
> here:
>=20
> https://www.acpica.org/documentation/
>=20
> 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)
>=20
> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6>