From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 31 11:42:33 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 CC9527DD;
Sun, 31 Mar 2013 11:42:33 +0000 (UTC)
(envelope-from kron24@gmail.com)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45])
by mx1.freebsd.org (Postfix) with ESMTP id 3CBE6908;
Sun, 31 Mar 2013 11:42:32 +0000 (UTC)
Received: by mail-ee0-f45.google.com with SMTP id b57so718572eek.18
for <multiple recipients>; Sun, 31 Mar 2013 04:42:31 -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=S7oCS5c/9TzmafKstzch9aPmi/PNfgX9pkbx13MAf8w=;
b=Au8Ybogs2kLkZf2lAr/PBDlTHooUz7pM7NkAQKrAZjhE8ZNsy6qNAYtPnvlAafLM/0
Yp5tWy0Q5RfL6cpf2RjtqMWPHgBFvmzKyuok2em2aE7vvHlEtlKM8xe4Z2Kgzek67vAK
rRGFCpyhWdnUR1WY8MgKsikocxsdEP6EFcrmWSzlhCMcSi/TcTP9YAkhJZOSofg4a5af
7rdNDF0txjbmzj/M99mhpX7P0sCvfE8NyUXUTCZeuPZGzPUTwh/FGIWeu3rDivmdlbyt
7f73m+oy+yRbnal9npasBxNoss9Wct/9zIaKN0vlqGA/2Ms8LOLcTHjt7rvYwyI7jpf1
aStg==
X-Received: by 10.14.215.193 with SMTP id e41mr26750489eep.32.1364730151804;
Sun, 31 Mar 2013 04:42:31 -0700 (PDT)
Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150])
by mx.google.com with ESMTPS id n2sm15080804eeo.10.2013.03.31.04.42.26
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 31 Mar 2013 04:42:31 -0700 (PDT)
Message-ID: <51582122.3050703@gmail.com>
Date: Sun, 31 Mar 2013 13:42:26 +0200
From: kron <kron24@gmail.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:17.0) Gecko/20130329 Thunderbird/17.0.4
MIME-Version: 1.0
To: David Demelier <demelier.david@gmail.com>
Subject: Re: panics due to buggy ACPI in Dell Latitude E6530?
References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org>
<2041632.on0aZtOfZI@melon> <227443103.MjG0Okhn3r@melon>
In-Reply-To: <227443103.MjG0Okhn3r@melon>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: freebsd-acpi@freebsd.org, Andriy Gapon <avg@freebsd.org>
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2013 11:42:33 -0000
On 2013/03/30 14:22, David Demelier wrote:
> Le samedi 30 mars 2013 14:13:53 David Demelier a écrit :
>> Le mercredi 27 février 2013 18:51:09 Andriy Gapon a écrit :
>>> on 27/02/2013 17:22 kron said the following:
>>>> Hi,
>>>>
>>>> I have a Dell notebook (Latitude E6530) on which I track
>>>> 9-STABLE. It served excellently until mid-Jan when it started
>>>> to panic a few times a week or so:
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 3; apic id = 03
>>>> fault virtual address = 0x10116
>>>> fault code = supervisor read data, page not present
>>>> instruction pointer = 0x20:0xffffffff802bc360
>>>> stack pointer = 0x28:0xffffff848f6db390
>>>> frame pointer = 0x28:0xffffff848f6db3c0
>>>> code segment = base 0x0, limit 0xfffff, type 0x1b
>>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags = interrupt enabled, resume, IOPL = 0
>>>> current process = 2199 (conky)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 3
>>>>
>>>> Before the panics kernel used to emit messages like:
>>>> ACPI Error: No object attached to node 0xfffffe00094a51c0
>>>> (20110527/exresnte-138)
>>>> ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node
>>>> 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113)
>>>
>>> This looks very much like a heisenbug reported several times here.
>>> E.g.:
>>> http://lists.freebsd.org/pipermail/freebsd-acpi/2012-December/007962.html
>>>
>>>> I suspected it started with a BIOS update (A07 -> A09).
>>>> Following the handbook, I took a look at acpidump. Sad to say,
>>>> it all was Greek to me, I could't even compile it back using
>>>> iasl (35 Errors). However, while skimming it I noticed names
>>>> of many versions of Windows and in addition to that, "Linux".
>>>> Just to try, I put hw.acpi.osname="Linux" to /boot/loader.conf.
>>>> Since that I've never get the panic again (for ~3 weeks).
>>>> I hope this is not just a coincidence.
>>>
>>> It very well could be.
>>>
>>>> Maybe this experience can help somebody else.
>>>>
>>>> If any of ACPI developers wants to play with the problem
>>>> I can provide more info (sorry, no crashdump, was not enabled),
>>>> do tests, etc.
>>>
>>> Please at least enable printing of a stack trace.
>>> Better do get the crash dump.
>>>
>>> P.S. I suspect that the issue we are discussing with hps in this mailing
>>> list could be related to this problem.
>>
>> About me, I've currently added the following to my /boot/loader.conf:
>>
>> debug.acpi.disabled="acad cmbat"
>>
>> And it solved my panics but unfortunately I must say bye to the battery
>> information.
>>
>> Regards,
>
> By the way, may be this is related? :)
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173408
>
> Cheers,
>
I'm sorry I forgot to update the thread - good you're reminding.
Andriy did a brilliant job at debugging the issue and I owe him
to say in public: Thank you, Andriy!
The results are:
- hw.acpi.osname="Linux" is not relevant
- there's some ACPICA issue Andriy took to discuss with other
hackers (and much above my competence to comment)
- a temporary workaround:
--- sys/dev/acpica/acpi_battery.c (revision 248682)
+++ sys/dev/acpica/acpi_battery.c (working copy)
@@ -360,6 +360,8 @@
int error, unit;
device_t dev;
+ mtx_lock(&Giant);
+
/* For commands that use the ioctl_arg struct, validate it first. */
error = ENXIO;
unit = 0;
@@ -417,6 +419,7 @@
error = EINVAL;
}
+ mtx_unlock(&Giant);
return (error);
}
The patch works for me without any problem. I guess it won't hurt
your system ;-) but I actually don't know if/how it relates to your
PR.
BR
Oli
From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 1 11:06:39 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 3BDB1804
for <freebsd-acpi@FreeBSD.org>; Mon, 1 Apr 2013 11:06:39 +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 1333D31E
for <freebsd-acpi@FreeBSD.org>; Mon, 1 Apr 2013 11:06:39 +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 r31B6c8d033552
for <freebsd-acpi@FreeBSD.org>; Mon, 1 Apr 2013 11:06:38 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r31B6cpN033550
for freebsd-acpi@FreeBSD.org; Mon, 1 Apr 2013 11:06:38 GMT
(envelope-from owner-bugmaster@FreeBSD.org)
Date: Mon, 1 Apr 2013 11:06:38 GMT
Message-Id: <201304011106.r31B6cpN033550@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: gnats set sender to
owner-bugmaster@FreeBSD.org using -f
From: FreeBSD bugmaster <bugmaster@freebsd.org>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 11:06:39 -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 Mon Apr 1 15:36:00 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 ECEA1715;
Mon, 1 Apr 2013 15:36:00 +0000 (UTC) (envelope-from jhb@freebsd.org)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
by mx1.freebsd.org (Postfix) with ESMTP id CAD90DC6;
Mon, 1 Apr 2013 15:36:00 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id F406DB91C;
Mon, 1 Apr 2013 11:35:59 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-acpi@freebsd.org
Subject: Re: call suspend_cpus() under smp_ipi_mtx
Date: Mon, 1 Apr 2013 10:52:18 -0400
User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; )
References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org>
In-Reply-To: <514D7A82.9000105@FreeBSD.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201304011052.18370.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Mon, 01 Apr 2013 11:36:00 -0400 (EDT)
Cc: freebsd-hackers@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>,
Andriy Gapon <avg@freebsd.org>
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 15:36:01 -0000
On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote:
>
> 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.
Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember
why we changed it to a regular mutex. It may be that there was a lock order reason
for that. :(
--
John Baldwin
From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 2 07:29:57 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 D3E3F142;
Tue, 2 Apr 2013 07:29:57 +0000 (UTC)
(envelope-from demelier.david@gmail.com)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54])
by mx1.freebsd.org (Postfix) with ESMTP id 49A8FD0C;
Tue, 2 Apr 2013 07:29:56 +0000 (UTC)
Received: by mail-wg0-f54.google.com with SMTP id a12so106166wgh.21
for <multiple recipients>; Tue, 02 Apr 2013 00:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:x-received:in-reply-to:references:date:message-id
:subject:from:to:cc:content-type:content-transfer-encoding;
bh=LODul5naF4zNDJqETFNifhsiUaeLvj9YjipBNU4g144=;
b=oz+4km7JS6izI+pZdgbDd6co8pnYW6EtiUyfPnePdqRuInPY/gwhrCFr+wRFWR6SF2
SCUJ7xP9f1slU6inItVuRz96GIoeO+rR5E1/JEar7H9XKP/ZW8D3O7I0DxUh3o24enTM
PybmJuBGkJjr+PcdwhrzeTLHqOTk608QseN+XLxASQIKyTxRUf4bp4D15SA+dRlYxjV+
mFxdpfmbI8x3ASE6hmeenPDPNmtp8YZ4SAE9hVhhIAaRWxLcDGAg4taIcDv18g4P6Iow
zWN1zaKmMEX09OgKCnFVfqQssncMDaWfryww9GGU/q1mTYjlsh1FRHVuPq9ETEpbU3Ld
aq5Q==
MIME-Version: 1.0
X-Received: by 10.180.92.97 with SMTP id cl1mr13692550wib.19.1364887796029;
Tue, 02 Apr 2013 00:29:56 -0700 (PDT)
Received: by 10.194.60.147 with HTTP; Tue, 2 Apr 2013 00:29:55 -0700 (PDT)
In-Reply-To: <51582122.3050703@gmail.com>
References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org>
<2041632.on0aZtOfZI@melon> <227443103.MjG0Okhn3r@melon>
<51582122.3050703@gmail.com>
Date: Tue, 2 Apr 2013 09:29:55 +0200
Message-ID: <CAO+PfDcPpQYuxfSS9gD7RwFF7N6z00aq2s5e63qE10g1BFWOig@mail.gmail.com>
Subject: Re: panics due to buggy ACPI in Dell Latitude E6530?
From: David Demelier <demelier.david@gmail.com>
To: kron <kron24@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: freebsd-acpi@freebsd.org, Andriy Gapon <avg@freebsd.org>
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 07:29:57 -0000
Hello,
Thanks for that small patch, I'm currently testing it and will tell
you how it works for me,
Cheers!
2013/3/31 kron <kron24@gmail.com>:
> On 2013/03/30 14:22, David Demelier wrote:
>> Le samedi 30 mars 2013 14:13:53 David Demelier a =C3=A9crit :
>>> Le mercredi 27 f=C3=A9vrier 2013 18:51:09 Andriy Gapon a =C3=A9crit :
>>>> on 27/02/2013 17:22 kron said the following:
>>>>> Hi,
>>>>>
>>>>> I have a Dell notebook (Latitude E6530) on which I track
>>>>> 9-STABLE. It served excellently until mid-Jan when it started
>>>>> to panic a few times a week or so:
>>>>>
>>>>> Fatal trap 12: page fault while in kernel mode
>>>>> cpuid =3D 3; apic id =3D 03
>>>>> fault virtual address =3D 0x10116
>>>>> fault code =3D supervisor read data, page not present
>>>>> instruction pointer =3D 0x20:0xffffffff802bc360
>>>>> stack pointer =3D 0x28:0xffffff848f6db390
>>>>> frame pointer =3D 0x28:0xffffff848f6db3c0
>>>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b
>>>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1
>>>>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0
>>>>> current process =3D 2199 (conky)
>>>>> trap number =3D 12
>>>>> panic: page fault
>>>>> cpuid =3D 3
>>>>>
>>>>> Before the panics kernel used to emit messages like:
>>>>> ACPI Error: No object attached to node 0xfffffe00094a51c0
>>>>> (20110527/exresnte-138)
>>>>> ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node
>>>>> 0xfffffe00094a51c0), AE_AML_NO_OPERAND (20110527/uteval-113)
>>>>
>>>> This looks very much like a heisenbug reported several times here.
>>>> E.g.:
>>>> http://lists.freebsd.org/pipermail/freebsd-acpi/2012-December/007962.h=
tml
>>>>
>>>>> I suspected it started with a BIOS update (A07 -> A09).
>>>>> Following the handbook, I took a look at acpidump. Sad to say,
>>>>> it all was Greek to me, I could't even compile it back using
>>>>> iasl (35 Errors). However, while skimming it I noticed names
>>>>> of many versions of Windows and in addition to that, "Linux".
>>>>> Just to try, I put hw.acpi.osname=3D"Linux" to /boot/loader.conf.
>>>>> Since that I've never get the panic again (for ~3 weeks).
>>>>> I hope this is not just a coincidence.
>>>>
>>>> It very well could be.
>>>>
>>>>> Maybe this experience can help somebody else.
>>>>>
>>>>> If any of ACPI developers wants to play with the problem
>>>>> I can provide more info (sorry, no crashdump, was not enabled),
>>>>> do tests, etc.
>>>>
>>>> Please at least enable printing of a stack trace.
>>>> Better do get the crash dump.
>>>>
>>>> P.S. I suspect that the issue we are discussing with hps in this maili=
ng
>>>> list could be related to this problem.
>>>
>>> About me, I've currently added the following to my /boot/loader.conf:
>>>
>>> debug.acpi.disabled=3D"acad cmbat"
>>>
>>> And it solved my panics but unfortunately I must say bye to the battery
>>> information.
>>>
>>> Regards,
>>
>> By the way, may be this is related? :)
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/173408
>>
>> Cheers,
>>
>
> I'm sorry I forgot to update the thread - good you're reminding.
> Andriy did a brilliant job at debugging the issue and I owe him
> to say in public: Thank you, Andriy!
>
> The results are:
> - hw.acpi.osname=3D"Linux" is not relevant
> - there's some ACPICA issue Andriy took to discuss with other
> hackers (and much above my competence to comment)
> - a temporary workaround:
>
> --- sys/dev/acpica/acpi_battery.c (revision 248682)
> +++ sys/dev/acpica/acpi_battery.c (working copy)
> @@ -360,6 +360,8 @@
> int error, unit;
> device_t dev;
>
> + mtx_lock(&Giant);
> +
> /* For commands that use the ioctl_arg struct, validate it first. */
> error =3D ENXIO;
> unit =3D 0;
> @@ -417,6 +419,7 @@
> error =3D EINVAL;
> }
>
> + mtx_unlock(&Giant);
> return (error);
> }
>
> The patch works for me without any problem. I guess it won't hurt
> your system ;-) but I actually don't know if/how it relates to your
> PR.
>
> BR
> Oli
--=20
Demelier David
From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 2 23:30:01 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
by hub.freebsd.org (Postfix) with ESMTP id 83F0472D
for <freebsd-acpi@smarthost.ysv.freebsd.org>;
Tue, 2 Apr 2013 23:30:01 +0000 (UTC)
(envelope-from gnats@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 5EE68379
for <freebsd-acpi@smarthost.ysv.freebsd.org>;
Tue, 2 Apr 2013 23:30:01 +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 r32NU1Fk007025
for <freebsd-acpi@freefall.freebsd.org>; Tue, 2 Apr 2013 23:30:01 GMT
(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r32NU1Gp007024;
Tue, 2 Apr 2013 23:30:01 GMT (envelope-from gnats)
Date: Tue, 2 Apr 2013 23:30:01 GMT
Message-Id: <201304022330.r32NU1Gp007024@freefall.freebsd.org>
To: freebsd-acpi@FreeBSD.org
Cc:
From: hiren panchasara <hiren.panchasara@gmail.com>
Subject: Re: kern/128634: [patch] fix acpi_asus(4) in asus a6f laptop
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: hiren panchasara <hiren.panchasara@gmail.com>
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 23:30:01 -0000
The following reply was made to PR kern/128634; it has been noted by GNATS.
From: hiren panchasara <hiren.panchasara@gmail.com>
To: bug-followup@FreeBSD.org, marcin.nowak@simplusnet.pl, rpaulo@freebsd.org
Cc:
Subject: Re: kern/128634: [patch] fix acpi_asus(4) in asus a6f laptop
Date: Tue, 2 Apr 2013 16:20:39 -0700
--089e01681d165529f304d968fc65
Content-Type: text/plain; charset=UTF-8
This has been MFCed.
Can we close this PR?
Thanks,
Hiren
--089e01681d165529f304d968fc65
Content-Type: text/html; charset=UTF-8
<div dir="ltr">This has been MFCed. <br><br>Can we close this PR?<br><br>Thanks,<br>Hiren<br></div>
--089e01681d165529f304d968fc65--
From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 3 15:24:27 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
by hub.freebsd.org (Postfix) with ESMTP id 76CCB936;
Wed, 3 Apr 2013 15:24:27 +0000 (UTC)
(envelope-from rpaulo@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 51CF4940;
Wed, 3 Apr 2013 15:24:27 +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 r33FORZt097826;
Wed, 3 Apr 2013 15:24:27 GMT
(envelope-from rpaulo@freefall.freebsd.org)
Received: (from rpaulo@localhost)
by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r33FOQY4097825;
Wed, 3 Apr 2013 15:24:26 GMT (envelope-from rpaulo)
Date: Wed, 3 Apr 2013 15:24:26 GMT
Message-Id: <201304031524.r33FOQY4097825@freefall.freebsd.org>
To: marcin.nowak@simplusnet.pl, rpaulo@FreeBSD.org, freebsd-acpi@FreeBSD.org
From: rpaulo@FreeBSD.org
Subject: Re: kern/128634: [patch] fix acpi_asus(4) in asus a6f laptop
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 15:24:27 -0000
Synopsis: [patch] fix acpi_asus(4) in asus a6f laptop
State-Changed-From-To: patched->closed
State-Changed-By: rpaulo
State-Changed-When: Wed Apr 3 15:23:34 UTC 2013
State-Changed-Why:
Fixed a long time ago.
http://www.freebsd.org/cgi/query-pr.cgi?pr=128634
From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 4 15:46:02 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 8A9DD846
for <freebsd-acpi@FreeBSD.org>; Thu, 4 Apr 2013 15:46:02 +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 D3563B48
for <freebsd-acpi@FreeBSD.org>; Thu, 4 Apr 2013 15:46:01 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
[212.40.38.101])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10424;
Thu, 04 Apr 2013 18:45:59 +0300 (EEST)
(envelope-from avg@FreeBSD.org)
Message-ID: <515DA036.5070206@FreeBSD.org>
Date: Thu, 04 Apr 2013 18:45:58 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:17.0) Gecko/20130313 Thunderbird/17.0.4
MIME-Version: 1.0
To: kron <kron24@gmail.com>, David Demelier <demelier.david@gmail.com>,
freebsd-acpi@FreeBSD.org
Subject: Re: panics due to buggy ACPI in Dell Latitude E6530?
References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org>
<2041632.on0aZtOfZI@melon> <227443103.MjG0Okhn3r@melon>
<51582122.3050703@gmail.com>
In-Reply-To: <51582122.3050703@gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 15:46:02 -0000
on 31/03/2013 14:42 kron said the following:
> I'm sorry I forgot to update the thread - good you're reminding.
> Andriy did a brilliant job at debugging the issue and I owe him
> to say in public: Thank you, Andriy!
I also apologize for not sharing the information promptly.
So here is a summary.
The problem turned out to be with the reference count in ACPICA. It doesn't have
any internal locking and so it relied on locks obtained by the callers. But not
all of the callers obtained the relevant locks (namespace, interpreter) and they
not really needed them (except for the reference counting). Also, our
acpi_battery driver uses ACPICA interfaces that were problematic. Additionally
the driver allows parallel queries, not sure if that is an intentional choice.
So now the ACPICA developers have fixed the reference counting code and no changes
in FreeBSD code should be required. We are just waiting for the next ACPICA release.
That's for head. Not sure which approach we will take for stable branches,
because we haven't been doing any MFCs of ACPICA imports. So there are tow choices:
- use the below patch to prevent parallel execution in the batter driver
- manually apply the specific reference count change to ACPICA code in the branches
Finally many thanks to Olli/kron for doing a lot of testing and debugging.
And many thanks to Tom Lislegaard who did a lot of testing and debugging too - in
our debugging session I reached all the same conclusions and came up with a
(different) patch, but then got distracted and completely forgot about the issue
until it resurfaced again.
> The results are:
> - hw.acpi.osname="Linux" is not relevant
> - there's some ACPICA issue Andriy took to discuss with other
> hackers (and much above my competence to comment)
> - a temporary workaround:
>
> --- sys/dev/acpica/acpi_battery.c (revision 248682)
> +++ sys/dev/acpica/acpi_battery.c (working copy)
> @@ -360,6 +360,8 @@
> int error, unit;
> device_t dev;
>
> + mtx_lock(&Giant);
> +
> /* For commands that use the ioctl_arg struct, validate it first. */
> error = ENXIO;
> unit = 0;
> @@ -417,6 +419,7 @@
> error = EINVAL;
> }
>
> + mtx_unlock(&Giant);
> return (error);
> }
>
> The patch works for me without any problem. I guess it won't hurt
> your system ;-) but I actually don't know if/how it relates to your
> PR.
--
Andriy Gapon
From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 4 15:47:58 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 8B01C88F
for <freebsd-acpi@FreeBSD.org>; Thu, 4 Apr 2013 15:47:58 +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 BD225B5D
for <freebsd-acpi@FreeBSD.org>; Thu, 4 Apr 2013 15:47:57 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
[212.40.38.101])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10446;
Thu, 04 Apr 2013 18:47:55 +0300 (EEST)
(envelope-from avg@FreeBSD.org)
Message-ID: <515DA0AB.80601@FreeBSD.org>
Date: Thu, 04 Apr 2013 18:47:55 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:17.0) Gecko/20130313 Thunderbird/17.0.4
MIME-Version: 1.0
To: David Demelier <demelier.david@gmail.com>
Subject: Re: panics due to buggy ACPI in Dell Latitude E6530?
References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org>
<2041632.on0aZtOfZI@melon> <227443103.MjG0Okhn3r@melon>
<51582122.3050703@gmail.com>
<CAO+PfDcPpQYuxfSS9gD7RwFF7N6z00aq2s5e63qE10g1BFWOig@mail.gmail.com>
In-Reply-To: <CAO+PfDcPpQYuxfSS9gD7RwFF7N6z00aq2s5e63qE10g1BFWOig@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 15:47:58 -0000
on 02/04/2013 10:29 David Demelier said the following:
> Thanks for that small patch, I'm currently testing it and will tell
> you how it works for me,
The best way to check is to run several
while true ; do acpiconf -i N ; done
in parallel.
If the system survives, then it will most likely survive the typical use too.
--
Andriy Gapon
From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 4 17:34:03 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 3B8E0A63;
Thu, 4 Apr 2013 17:34:03 +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 C70332B8;
Thu, 4 Apr 2013 17:34:01 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
[212.40.38.101])
by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11680;
Thu, 04 Apr 2013 20:34:00 +0300 (EEST)
(envelope-from avg@FreeBSD.org)
Message-ID: <515DB988.1080100@FreeBSD.org>
Date: Thu, 04 Apr 2013 20:34:00 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:17.0) Gecko/20130313 Thunderbird/17.0.4
MIME-Version: 1.0
To: John Baldwin <jhb@FreeBSD.org>
Subject: Re: call suspend_cpus() under smp_ipi_mtx
References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org>
<201304011052.18370.jhb@freebsd.org>
In-Reply-To: <201304011052.18370.jhb@freebsd.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org,
FreeBSD Current <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 17:34:03 -0000
on 01/04/2013 17:52 John Baldwin said the following:
> Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember
> why we changed it to a regular mutex. It may be that there was a lock order reason
> for that. :(
I came up with the following patch:
http://people.freebsd.org/~avg/intr_table_lock.diff
Please note the witness change. Part of it is to prepare for smp_ipi_mtx ->
intr_table_lock order, but I also had to move "entropy harvest mutex" because it
is used with msleep_spin. Also intr_table_lock interacts with "sched lock".
This seems to work without problems or any warnings with WITNESS &&
!WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the
relevant code paths.
P.S. Looking through history it seems that in r169391 intr_table_lock
was changed from a spinlock to a sx lock (later it was changed to the current
mutex). The commit message explains why spinlock was not needed, but it doesn't
seem to say why it was unacceptable:
> Minor fixes and tweaks to the x86 interrupt code: - Split the intr_table_lock
into an sx lock used for most things, and a spin lock to protect intrcnt_index.
Originally I had this as a spin lock so interrupt code could use it to lookup
sources. However, we don't actually do that because it would add a lot of overhead
to interrupts, and if we ever do support removing interrupt sources, we can use
other means to safely do so w/o locking in the interrupt handling code. - Replace
is_enabled (boolean) with is_handlers (a count of handlers) to determine if a
source is enabled or not. This allows us to notice when a source is no longer in
use. When that happens, we now invoke a new PIC method (pic_disable_intr()) to
inform the PIC driver that the source is no longer in use. The I/O APIC driver
frees the APIC IDT vector when this happens. The MSI driver no longer needs to
have a hack to clear is_enabled during msi_alloc() and msix_alloc() as a result of
this change as well. - Add an apic_disable_vector() to reset an IDT vector back to
Xrsvd to complement apic_enable_vector() and use it in the I/O APIC and MSI code
when freeing an IDT vector. - Add a new nexus hook: nexus_add_irq() to ask the
nexus driver to add an IRQ to its irq_rman. The MSI code uses this when it creates
new interrupt sources to let the nexus know about newly valid IRQs. Previously the
msi_alloc() and msix_alloc() passed some extra stuff back to the nexus methods
which then added the IRQs. This approach is a bit cleaner. - Change the MSI sx
lock to a mutex. If we need to create new sources, drop the lock, create the
required number of sources, then get the lock and try the allocation again.
--
Andriy Gapon
From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 6 17:14:48 2013
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 BD91BD22;
Sat, 6 Apr 2013 17:14:48 +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 6F2C278D;
Sat, 6 Apr 2013 17:14:46 +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 UAA04486;
Sat, 06 Apr 2013 20:14:45 +0300 (EEST)
(envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
id 1UOWhR-0006CP-70; Sat, 06 Apr 2013 20:14:45 +0300
Message-ID: <51605804.8080906@FreeBSD.org>
Date: Sat, 06 Apr 2013 20:14:44 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:17.0) Gecko/20130405 Thunderbird/17.0.5
MIME-Version: 1.0
To: John Baldwin <jhb@FreeBSD.org>
Subject: Re: call suspend_cpus() under smp_ipi_mtx
References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org>
<201304011052.18370.jhb@freebsd.org> <515DB988.1080100@FreeBSD.org>
In-Reply-To: <515DB988.1080100@FreeBSD.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org,
FreeBSD Current <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Apr 2013 17:14:48 -0000
on 04/04/2013 20:34 Andriy Gapon said the following:
> This seems to work without problems or any warnings with WITNESS &&
> !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the
> relevant code paths.
>
> P.S. Looking through history it seems that in r169391 intr_table_lock
> was changed from a spinlock to a sx lock (later it was changed to the current
> mutex). The commit message explains why spinlock was not needed, but it doesn't
> seem to say why it was unacceptable:
Hmm, looks like I missed the elephant.
apic_free_vector is called with intr_table_lock held and it calls sched_bind().
I need to re-think all of think from the scratch...
--
Andriy Gapon