From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 17 11:42:22 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 A20377F8; Sun, 17 Mar 2013 11:42:22 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id F0E82D28; Sun, 17 Mar 2013 11:42:21 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so2153780eek.36 for ; Sun, 17 Mar 2013 04:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9rZ/0V1OHp0QGEHocTEp/aDhc6g4XKS8epYbMfw5yVQ=; b=Qp8d1lPD/IABqm3FTgQbg7KCMGFFF8Nueolzpawu4o9fvSRZjPvpYJMm6QPW9jnTqo lbWJb4lOHsQKKmHIYwVsgd6yGeIYNSIBeA/sAZHMv+8YEDjKnR+NHv/+GTI1pfnmPtpC oEwJ1BHHCX17mJnktlUsn9k5emJyFOVp40E13MM+WBaqgMhp5oI/oVQuJdGzHcTlDBOA 9DaT0fit3PzjexoCFugw/wxiBNHlE3CyPgdztaaJgnLsYxv5AD57FzmmXMacVtAvQ0rw fAogyj3Rqhoyl+PiCWjKMfSpLMp5X9M3XA77c6nN4HFu1SEM9C+85KJiQuhurBTmwoay IyCA== X-Received: by 10.14.4.69 with SMTP id 45mr37937611eei.0.1363520535309; Sun, 17 Mar 2013 04:42:15 -0700 (PDT) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id m46sm20975019eeo.16.2013.03.17.04.42.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 04:42:14 -0700 (PDT) Message-ID: <5145AC15.5080008@gmail.com> Date: Sun, 17 Mar 2013 12:42:13 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org> <513395D1.8090500@gmail.com> <5135EF5D.2050909@FreeBSD.org> <513C9587.1040801@gmail.com> <513E4C89.30604@FreeBSD.org> In-Reply-To: <513E4C89.30604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sun, 17 Mar 2013 11:42:22 -0000 On 2013/03/11 22:28, Andriy Gapon wrote: ... >>> In either case, could you please try the following patch (it is against recent >>> stable/9) ? >>> http://people.freebsd.org/~avg/OsdSynch-9.diff ... > The following patch might also be of use with _debugging_ this issue: > http://people.freebsd.org/~avg/acpi-uma-cache.diff Hi Andryi, 9.1-STABLE #0 r248230M - with the two patches mentioned above panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ACPI Error: Object not a Integer, type Reference (20110527/exresnte-209) ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node 0xfffffe0008496938), AE_AML_OPERAND_TYPE (20110527/uteval-113) ... #0 doadump (textdump=) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:229 #1 0xffffffff80471b64 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff80471fa4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff806c02c5 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:878 #4 0xffffffff806c0663 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:735 #5 0xffffffff806bfcae in trap (frame=0xffffff80003025f0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff806aa233 in calltrap () at exception.S:228 #7 0xffffffff802add43 in AcpiExStore (SourceDesc=, DestDesc=0xfffffe03eed84090, WalkState=) at /usr/src/sys/contrib/dev/acpica/executer/exstore.c:288 #8 0xffffffff802ab468 in AcpiExOpcode_1A_1T_1R (WalkState=0xfffffe0013abdc00) at /usr/src/sys/contrib/dev/acpica/executer/exoparg1.c:502 #9 0xffffffff802a2ebd in AcpiDsExecEndOp (WalkState=0xfffffe0013abdc00) at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:475 #10 0xffffffff802b613e in AcpiPsParseLoop (WalkState=0xfffffe0013abdc00) at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249 #11 0xffffffff802b69cd in AcpiPsParseAml (WalkState=) at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525 #12 0xffffffff802b7517 in AcpiPsExecuteMethod (Info=0xfffffe027c59f980) at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368 #13 0xffffffff802b11e6 in AcpiNsEvaluate (Info=0xfffffe027c59f980) at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193 #14 0xffffffff802b4318 in AcpiEvaluateObject (Handle=0xfffffe000848f640, Pathname=, ExternalParams=, ReturnBuffer=0xffffff8000302988) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfeval.c:289 #15 0xffffffff802cd84a in acpi_cpu_cx_cst (sc=0xfffffe0008463200) at /usr/src/sys/dev/acpica/acpi_cpu.c:735 #16 0xffffffff802cdb9b in acpi_cpu_notify (h=, notify=, context=0xfffffe0008463200) at /usr/src/sys/dev/acpica/acpi_cpu.c:1104 #17 0xffffffff802a5fa1 in AcpiEvNotifyDispatch (Context=0xfffffe0013e0e3c0) at /usr/src/sys/contrib/dev/acpica/events/evmisc.c:283 #18 0xffffffff802c38b0 in acpi_task_execute (context=0xffffff80009d4000, pending=333443472) at /usr/src/sys/dev/acpica/Osd/OsdSchedule.c:134 #19 0xffffffff804b2fa6 in taskqueue_run_locked (queue=0xfffffe000841ba80) at /usr/src/sys/kern/subr_taskqueue.c:312 #20 0xffffffff804b3818 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:501 #21 0xffffffff80446045 in fork_exit ( callout=0xffffffff804b3780 , arg=0xffffffff80abcc68, frame=0xffffff8000302b00) at /usr/src/sys/kern/kern_fork.c:988 #22 0xffffffff806aa76e in fork_trampoline () at exception.S:602 #23 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) I have the crash dump. BR Oli From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 18 11:06:38 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2108184D for ; Mon, 18 Mar 2013 11:06:38 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ED79FA9B for ; Mon, 18 Mar 2013 11:06:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2IB6boE002040 for ; Mon, 18 Mar 2013 11:06:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2IB6bmm002038 for freebsd-acpi@FreeBSD.org; Mon, 18 Mar 2013 11:06:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Mar 2013 11:06:37 GMT Message-Id: <201303181106.r2IB6bmm002038@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 18 Mar 2013 11:06:38 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] [patch] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 34 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 20 08:34:53 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 72A1A10F; Wed, 20 Mar 2013 08:34:53 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8BA3FB; Wed, 20 Mar 2013 08:34:52 +0000 (UTC) Received: from [217.76.201.82] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UIDyG-000IJO-A6; Wed, 20 Mar 2013 10:02:09 +0200 Message-ID: <51496CF7.1040604@shurik.kiev.ua> Date: Wed, 20 Mar 2013 10:01:59 +0200 From: Alexandr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 217.76.201.82 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on graal.it-profi.org.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 Subject: acpi_video on ThinkPad E530 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on graal.it-profi.org.ua) Cc: freebsd-mobile@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, 20 Mar 2013 08:34:53 -0000 Hello! On my laptop with acpi_video loaded brightness control via Fn-keys doesn't work. The only way to change brightness is using dev.acpi_ibm.0.lcd_brightness, for example: /bin/sh -c 'LEVEL=$(/sbin/sysctl -n dev.acpi_ibm.0.lcd_brightness) ;/sbin/sysctl dev.acpi_ibm.0.lcd_brightness=$(/bin/expr $LEVEL + 1)' When I press Fn-key I see, that hw.acpi.video.lcd0.brightness is changed, but nothing happens on screen. I think it because of hw.acpi.video.lcd0.active=0, but I cannot change it. With acpi_ibm and without acpi_video Fn-keys works well. From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 21 16:43:59 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80C10A8A; Thu, 21 Mar 2013 16:43:59 +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 6211AA7A; Thu, 21 Mar 2013 16:43:59 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 21 Mar 2013 09:43:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,887,1355126400"; d="scan'208";a="306477279" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga001.fm.intel.com with ESMTP; 21 Mar 2013 09:43:52 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 21 Mar 2013 09:43:52 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.213]) by ORSMSX152.amr.corp.intel.com ([169.254.8.185]) with mapi id 14.01.0355.002; Thu, 21 Mar 2013 09:43:52 -0700 From: "Moore, Robert" To: Jung-uk Kim , Hans Petter Selasky Subject: RE: ACPI locking bugs? Thread-Topic: ACPI locking bugs? Thread-Index: AQHOFPHG6NrttiKZBk2hHOKVWhXgJpiOnWIA//+K//CAIlPLMA== Date: Thu, 21 Mar 2013 16:43:51 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E36F48ADF4@ORSMSX101.amr.corp.intel.com> References: <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org> <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E36F4764A6@ORSMSX101.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] 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: Thu, 21 Mar 2013 16:43:59 -0000 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" From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 23 09:48:56 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 1BC84BFD; Sat, 23 Mar 2013 09:48:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E8C2FD32; Sat, 23 Mar 2013 09:48:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15528; Sat, 23 Mar 2013 11:48:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UJL4G-000Dtf-O0; Sat, 23 Mar 2013 11:48:52 +0200 Message-ID: <514D7A82.9000105@FreeBSD.org> Date: Sat, 23 Mar 2013 11:48:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> In-Reply-To: <5114AB2E.2050909@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit 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: Sat, 23 Mar 2013 09:48:56 -0000 Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU could be holding smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), while another CPU could be with interrupts disabled (explicitly - like in the shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a deadlock is quite possible. Some obstacles for just going ahead and making the suggested change: - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we would have to make intr_table_lock and msi_lock the spin-locks as well; - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and currently it performs an action that requires memory allocation; again, with interrupts disabled via intr_disable() this fact is not visible to witness, etc, but with smp_ipi_mtx it needs to be somehow handled. I talked to ACPICA guys about the last issue and they told me that what is currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and _GTS support was removed. What do you think? Thank you. -- Andriy Gapon