From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 20:35:03 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A63EBF1; Wed, 27 Feb 2013 20:35:03 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 421F9DB9; Wed, 27 Feb 2013 20:35:03 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 27 Feb 2013 12:33:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,750,1355126400"; d="scan'208";a="292704295" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 27 Feb 2013 12:33:55 -0800 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Feb 2013 12:33:55 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.110]) by ORSMSX151.amr.corp.intel.com ([169.254.7.6]) with mapi id 14.01.0355.002; Wed, 27 Feb 2013 12:33:54 -0800 From: "Moore, Robert" To: Jung-uk Kim , Hans Petter Selasky Subject: RE: ACPI locking bugs? Thread-Topic: ACPI locking bugs? Thread-Index: AQHOFPHG6NrttiKZBk2hHOKVWhXgJpiOnWIA//+K//A= Date: Wed, 27 Feb 2013 20:33:53 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> In-Reply-To: <512E5E4C.807@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:35:03 -0000 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"