From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 3 18:26:29 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E12F755; Sun, 3 Mar 2013 18:26:29 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id 978EC22D; Sun, 3 Mar 2013 18:26:28 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id t10so3501135eei.21 for ; Sun, 03 Mar 2013 10:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9thiXs7UTZVhfFoEKDFayirs2wkHy6nnSAjFinLPuvU=; b=d0jdmlT6k4inKg6VHvKXCF+P1uEsyBn1sk4zwStkakUKbbt+K59E1PVKpXikdSKVS9 j+11tn5ikmpRUFC1nNtP5pno7r4iooA7DIjSbj0AKOa4LJrzhHep4Q5mgp4A0v4CGTLW qZonx5+MSh63jqwF2FH/gpMe2mgPODFF0b5CCEChvzX+jyCPUSdYiSMK9RC+hSPhv2KK 00If+U9tFzP2SklVF2aii4wWBgg5fEs2WmCEhYeuvEcEZfNpWeqhyTGV7rce1dScnrQW SIQdUHYDjMneyN90/ud8CWM7px6eRQVNU2Kg70c3UPdo4be8KK1MvzL/HmsTDcdCbJBI dlIA== X-Received: by 10.14.5.6 with SMTP id 6mr50454316eek.42.1362335187261; Sun, 03 Mar 2013 10:26:27 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id z45sm7594668eeu.10.2013.03.03.10.26.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 10:26:26 -0800 (PST) Message-ID: <513395D1.8090500@gmail.com> Date: Sun, 03 Mar 2013 19:26:25 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130225 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: panics due to buggy ACPI in Dell Latitude E6530? References: <512E24CD.9090404@gmail.com> <512E397D.1070406@FreeBSD.org> In-Reply-To: <512E397D.1070406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 18:26:29 -0000 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=) 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=) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff806c1ce5 in trap_fatal (frame=,. eva=) at /usr/src/sys/amd64/amd64/trap.c:878 #4 0xffffffff806c1984 in trap (frame=) 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, ComponentId=64,. Type=1) at /usr/src/sys/contrib/dev/acpica/utilities/utobject.c:437 #8 0xffffffff802a3e05 in AcpiDsCreateOperand (WalkState=0xfffffe000b5c8c00,. Arg=0xfffffe000b665480, ArgIndex=) at /usr/src/sys/contrib/dev/acpica/dispatcher/dsutils.c:703 #9 0xffffffff802a3f0e in AcpiDsCreateOperands (WalkState=0xfffffe000b5c8c00,. FirstArg=) 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=) 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,. Flags=0xfffffe019451f098) at /usr/src/sys/contrib/dev/acpica/utilities/uteval.c:276 #17 0xffffffff802b6002 in AcpiGetObjectInfo (Handle=,. ReturnBuffer=0xffffff848f9ce758) at /usr/src/sys/contrib/dev/acpica/namespace/nsxfname.c:423 #18 0xffffffff802c66ce in acpi_BatteryIsPresent (dev=) at /usr/src/sys/dev/acpica/acpi.c:2065 #19 0xffffffff802cc7c4 in acpi_battery_get_battinfo (dev=0x0,. battinfo=0xffffffff80a10610) at /usr/src/sys/dev/acpica/acpi_battery.c:176 #20 0xffffffff802cce5f in acpi_battery_sysctl (oidp=0xfffffe000b589b00,. arg1=, arg2=64, req=0xffffff848f9ce8a8) at /usr/src/sys/dev/acpica/acpi_battery.c:428 #21 0xffffffff8047de1d in sysctl_root (arg1=,. arg2=) at /usr/src/sys/kern/kern_sysctl.c:1527 #22 0xffffffff8047e3b8 in userland_sysctl (td=,. name=0xffffff848f9ce970, namelen=,. old=, oldlenp=,. inkernel=, new=,. newlen=, retval=,. 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 (kgdb). 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). /etc/make.conf: CC=clang CXX=clang++ CPP=clang-cpp CPUTYPE?=native CFLAGS+= -fno-stack-protector Oli