Date: Sat, 20 Apr 2013 02:13:08 -0700 (PDT) From: David Demelier <demelier.david@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-acpi@freebsd.org, kron <kron24@gmail.com> Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? Message-ID: <2514081.nyTdW5Saad@melon> In-Reply-To: <515DA036.5070206@FreeBSD.org> References: <512E24CD.9090404@gmail.com> <51582122.3050703@gmail.com> <515DA036.5070206@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2514081.nyTdW5Saad>