panics due to buggy ACPI in Dell Latitude E6530?
David Demelier
demelier.david at gmail.com
Tue Apr 2 07:29:57 UTC 2013
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 at gmail.com>:
> 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
--
Demelier David
More information about the freebsd-acpi
mailing list