From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 20 09:13:12 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 A619F56F; Sat, 20 Apr 2013 09:13:12 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 1974013D6; Sat, 20 Apr 2013 09:13:11 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id c10so1927958wiw.6 for ; Sat, 20 Apr 2013 02:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=T27N221VBQcgew8IAzQ1DghAk2SCGeiszqjN+mxAzj4=; b=bm30PzLAa7a2465hiBdDzqJ/VLbVLhB2aHk4EVyjulc9dd8L+lsccizn9KLmCmwos3 fZtNHstwwLL/fD3BliFmUJryhdh8nHnWmdRjvBIA42rIKnStZsBlnUul041ZQDyXTDFs 7fLfZJd0gR5MBjwuZo0cpo2q7uXNVtEc9/LoPL4UadbGmCSog7hS8fsR6Kmtf3ca5o5S wsYOXs2rdApMYSlWYEbtEjV/xOLpf1FWmONYNT+ojComTBiB5RK0H1zzrevNPZKB8AqP NDXhlMG138Mfs9VoDwGFM2NOGM2qa6SgwZlJ0XnRlsOP3Y+1UUoGniKI3wQTs9tfAfNY /7PA== X-Received: by 10.180.92.229 with SMTP id cp5mr10453485wib.20.1366449190103; Sat, 20 Apr 2013 02:13:10 -0700 (PDT) Received: from melon.localnet (11.33.91.91.rev.sfr.net. [91.91.33.11]) by mx.google.com with ESMTPS id o3sm8551185wia.2.2013.04.20.02.13.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 02:13:08 -0700 (PDT) From: David Demelier To: Andriy Gapon Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? Date: Sat, 20 Apr 2013 02:13:08 -0700 (PDT) Message-ID: <2514081.nyTdW5Saad@melon> User-Agent: KMail/4.10.1 (FreeBSD/9.1-RELEASE-p1; KDE/4.10.1; amd64; ; ) In-Reply-To: <515DA036.5070206@FreeBSD.org> References: <512E24CD.9090404@gmail.com> <51582122.3050703@gmail.com> <515DA036.5070206@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-acpi@freebsd.org, kron 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, 20 Apr 2013 09:13:12 -0000 Le jeudi 4 avril 2013 18:45:58 Andriy Gapon a =E9crit : > 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! >=20 > I also apologize for not sharing the information promptly. >=20 > So here is a summary. >=20 > 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 inter= faces > that were problematic. Additionally the driver allows parallel queri= es, > not sure if that is an intentional choice. >=20 > So now the ACPICA developers have fixed the reference counting code a= nd 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 wil= l 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 >=20 > Finally many thanks to Olli/kron for doing a lot of testing and debug= ging. > And many thanks to Tom Lislegaard who did a lot of testing and debugg= ing too > - in our debugging session I reached all the same conclusions and cam= e up > with a (different) patch, but then got distracted and completely forg= ot > about the issue until it resurfaced again. >=20 Thanks a lot for the very detailed explanation. For now I'll use the pa= tch=20 until the acpica release is merge into the next FreeBSD release :-). Regards, > > The results are: > > - hw.acpi.osname=3D"Linux" is not relevant > > - there's some ACPICA issue Andriy took to discuss with other > > =20 > > hackers (and much above my competence to comment) > > =20 > > - a temporary workaround: > > --- sys/dev/acpica/acpi_battery.c (revision 248682) > > +++ sys/dev/acpica/acpi_battery.c (working copy) > > @@ -360,6 +360,8 @@ > >=20 > > int error, unit; > > device_t dev; > >=20 > > + mtx_lock(&Giant); > > + > >=20 > > /* For commands that use the ioctl_arg struct, validate it fir= st. */ > > error =3D ENXIO; > > unit =3D 0; > >=20 > > @@ -417,6 +419,7 @@ > >=20 > > error =3D EINVAL; > > =20 > > } > >=20 > > + mtx_unlock(&Giant); > >=20 > > return (error); > > =20 > > } > >=20 > > 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. --=20 David Demelier