Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Mar 2013 13:42:26 +0200
From:      kron <kron24@gmail.com>
To:        David Demelier <demelier.david@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:  <51582122.3050703@gmail.com>
In-Reply-To: <227443103.MjG0Okhn3r@melon>
References:  <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org> <2041632.on0aZtOfZI@melon> <227443103.MjG0Okhn3r@melon>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51582122.3050703>