On 2013/02/27 17:51, Andriy Gapon wrote:
> 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
> Please at least enable printing of a stack trace.
> Better do get the crash dump.

from core.txt.1:

(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:229
#1  0xffffffff80473524 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:448
#2  0xffffffff80473964 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:636
#3  0xffffffff806c1ce5 in trap_fatal (frame=<value optimized out>,.
    eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:878
#4  0xffffffff806c1984 in trap (frame=<value optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:224
#5  0xffffffff806abc53 in calltrap () at exception.S:228
#6  0xffffffff802bc850 in AcpiOsAcquireObject (Cache=0xfffffe00093a14a0)
    at /usr/src/sys/contrib/dev/acpica/utilities/utcache.c:310
#7  0xffffffff802bf481 in AcpiUtCreateInternalObjectDbg (
    ModuleName=0xffffffff8071c1a6 "dsutils", LineNumber=703,
    Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437
#8  0xffffffff802a3e05 in AcpiDsCreateOperand
    Arg=0xfffffe000b665480, ArgIndex=<value optimized out>)
    at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703
#9  0xffffffff802a3f0e in AcpiDsCreateOperands
    FirstArg=<value optimized out>)
    at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:798
#10 0xffffffff802a4699 in AcpiDsExecEndOp (WalkState=0xfffffe000b5c8c00)
    at /usr/src/sys/contrib/dev/acpica/dispatcher/dswexec.c:567
#11 0xffffffff802b766e in AcpiPsParseLoop (WalkState=0xfffffe000b5c8c00)
    at /usr/src/sys/contrib/dev/acpica/parser/psloop.c:1249
#12 0xffffffff802b7efd in AcpiPsParseAml (WalkState=<value optimized out>)
    at /usr/src/sys/contrib/dev/acpica/parser/psparse.c:525
#13 0xffffffff802b8a47 in AcpiPsExecuteMethod (Info=0xfffffe0185417280)
    at /usr/src/sys/contrib/dev/acpica/parser/psxface.c:368
#14 0xffffffff802b2716 in AcpiNsEvaluate (Info=0xfffffe0185417280)
    at /usr/src/sys/contrib/dev/acpica/namespace/nseval.c:193
#15 0xffffffff802bda6d in AcpiUtEvaluateObject (
    PrefixNode=0xfffffe00094a4180, Path=0xffffffff80721a6b "_STA",.
    ExpectedReturnBtypes=1, ReturnDesc=0xffffff848f9ce6b0)
    at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:102
#16 0xffffffff802bdc1e in AcpiUtExecute_STA (DeviceNode=0xfffffe0009473780,.
    at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276
#17 0xffffffff802b6002 in AcpiGetObjectInfo (Handle=<value optimized out>,.
    at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423
#18 0xffffffff802c66ce in acpi_BatteryIsPresent (dev=<value optimized out>)
    at /usr/src/sys/dev/acpica/acpi.c:2065
#19 0xffffffff802cc7c4 in acpi_battery_get_battinfo (dev=0x0,.
    battinfo=0xffffffff80a10610) at
#20 0xffffffff802cce5f in acpi_battery_sysctl (oidp=0xfffffe000b589b00,.
    arg1=<value optimized out>, arg2=64, req=0xffffff848f9ce8a8)
    at /usr/src/sys/dev/acpica/acpi_battery.c:428
#21 0xffffffff8047de1d in sysctl_root (arg1=<value optimized out>,.
    arg2=<value optimized out>) at /usr/src/sys/kern/kern_sysctl.c:1527
#22 0xffffffff8047e3b8 in userland_sysctl (td=<value optimized out>,.
    name=0xffffff848f9ce970, namelen=<value optimized out>,.
    old=<value optimized out>, oldlenp=<value optimized out>,.
    inkernel=<value optimized out>, new=<value optimized out>,.
    newlen=<value optimized out>, retval=<value optimized out>,.
    flags=-1885542256) at /usr/src/sys/kern/kern_sysctl.c:1637
#23 0xffffffff8047e1a4 in sys___sysctl (td=0xfffffe008382f000,.
    uap=0xffffff848f9cea80) at /usr/src/sys/kern/kern_sysctl.c:1563
#24 0xffffffff806c24a4 in amd64_syscall (td=0xfffffe008382f000, traced=0)
    at subr_syscall.c:135
#25 0xffffffff806abf3b in Xfast_syscall () at exception.S:387
#26 0x000000080281e78c in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

I still have the vmcore. Is anything interesting we can get
from this?

It was on a pretty fresh clang-built 9-STABLE with a custom
kernel (minimized, more or less).

CFLAGS+= -fno-stack-protector

freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to