Date: Tue, 2 Apr 2013 09:29:55 +0200 From: David Demelier <demelier.david@gmail.com> To: kron <kron24@gmail.com> Cc: freebsd-acpi@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? Message-ID: <CAO%2BPfDcPpQYuxfSS9gD7RwFF7N6z00aq2s5e63qE10g1BFWOig@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAO%2BPfDcPpQYuxfSS9gD7RwFF7N6z00aq2s5e63qE10g1BFWOig>