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 <[email protected]>: > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
