From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 8 04:26:46 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A1C8F6AE; Sun, 8 Sep 2013 04:26:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 126032785; Sun, 8 Sep 2013 04:26:45 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id c10so2228334wiw.5 for ; Sat, 07 Sep 2013 21:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=i5cbn1qSzmZlVbvLBmy6FlD6JZodUoeI3F9Ty9zXgUU=; b=cYZ2Er+UaJEMFUFd4FITfqb6nckU9XlCuRqFHtbMhsM0xHHAgBe5bM6gzRSP94BSRR s9fPNZ3c3mk7gCbWD9KfrqM+dAxQpYOjV7qbcoPYMepuYBow2i/36oJPQjtxIAiH/QGD lErir0p94hv71LiUcRDAiJJG2cT4GO3zxGU588MqX0HjR/iduwznHLUaanvNhbFOvUqb p3rUQQPkUwkaZKIyum0CasUepkB/5MfwkpTAXHKG1UZsMqjHsgzEWV4TjMosi+eYBtqg YXTag36JDJ0IPI9pdPew+V7gZz7dhGAiqq73ifA30JFNeS3ksKoktIwR7TZ1enlMYZBn tJ8w== MIME-Version: 1.0 X-Received: by 10.194.123.227 with SMTP id md3mr7929686wjb.17.1378614404492; Sat, 07 Sep 2013 21:26:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Sat, 7 Sep 2013 21:26:44 -0700 (PDT) Date: Sat, 7 Sep 2013 21:26:44 -0700 X-Google-Sender-Auth: 7MPxJbymNgiR6pAdxEbAK3hbV_Y Message-ID: Subject: Update: Lenovo X230, suspend/resume From: Adrian Chadd To: "freebsd-acpi@freebsd.org" , "freebsd-mobile@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 08 Sep 2013 04:26:46 -0000 Hi, I've just updated to the latest -HEAD. * if I leave VESA in, then suspend works; resume brings the backlight back but not the video screen. Same behavour in X and console. * If I leave VESA out, then suspend works; resume doesn't restore the backlight. Same behaviour in X and console. Does anyone have any ideas on this? Thanks, -adrian From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 8 21:25:05 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C437C27 for ; Sun, 8 Sep 2013 21:25:05 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CCDF225C for ; Sun, 8 Sep 2013 21:25:04 +0000 (UTC) Received: from pool-96-233-20-106.bstnma.east.verizon.net ([96.233.20.106] helo=homobox.opal.com) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VImTZ-000Bmb-PS for freebsd-acpi@freebsd.org; Sun, 08 Sep 2013 21:24:57 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r88LOsne038145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 8 Sep 2013 17:24:55 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 96.233.20.106 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18JwcQJ1+HEjeMEnH1PN4je Date: Sun, 8 Sep 2013 17:24:54 -0400 From: "J.R. Oldroyd" To: freebsd-acpi@freebsd.org Subject: panic after acpi suspend/resume 9.1, 9.2rc3 Message-ID: <20130908172454.15812086@shibato> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Sun, 08 Sep 2013 17:24:55 -0400 (EDT) X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, RP_MATCHES_RCVD shortcircuit=no autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com 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, 08 Sep 2013 21:25:05 -0000 This problem may have existed for some time in the 9.x kernel. I've had similar panics for a while, but not had time to look into it. I did not have this problem on 8.x kernels on this laptop. It never happens when the system is cold-booted. It only happens after a suspend/resume cycle or two which is why I am posting to freebsd-apci to start with... The repeat-by goes something like this: - boot system - suspend system - resume system - use as normal (mix of email/firefox/sh & nvi/openvpn) - perhaps suspend/resume again - keep using as normal - system panics, seems often to be when using firefox Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80ceddcd stack pointer = 0x28:0xffffff80dbfe25e0 frame pointer = 0x28:0xffffff80dbfe2660 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 = 52022 (firefox) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80947986 at kdb_backtrace+0x66 #1 0xffffffff8090d9ae at panic+0x1ce #2 0xffffffff80cf1db0 at trap_fatal+0x290 #3 0xffffffff80cf2111 at trap_pfault+0x211 #4 0xffffffff80cf26c4 at trap+0x344 #5 0xffffffff80cdb9f3 at calltrap+0x8 #6 0xffffffff80b797a7 at vm_fault_hold+0x1b87 #7 0xffffffff80b7a343 at vm_fault+0x73 #8 0xffffffff80cf202f at trap_pfault+0x12f #9 0xffffffff80cf2874 at trap+0x4f4 #10 0xffffffff80cdb9f3 at calltrap+0x8 Uptime: 3d1h54m0s Dumping 409 out of 2918 MB:..4%..12%..24%..32%..43%..51%..63%..71%..83%..94% Reading symbols from... #0 doadump (textdump=) at pcpu.h:234 234 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) up 9 #9 0xffffffff80b7a343 in vm_fault (map=0xfffffe00862457a8, vaddr=35020902400, fault_type=, fault_flags=0) at ../../../vm/vm_fault.c:229 229 result = vm_fault_hold(map, trunc_page(vaddr), fault_type, fault_flags, (kgdb) list 224 return (KERN_PROTECTION_FAILURE); 225 #ifdef KTRACE 226 if (map != kernel_map && KTRPOINT(td, KTR_FAULT)) 227 ktrfault(vaddr, fault_type); 228 #endif 229 result = vm_fault_hold(map, trunc_page(vaddr), fault_type, fault_flags, 230 NULL); 231 #ifdef KTRACE 232 if (map != kernel_map && KTRPOINT(td, KTR_FAULTEND)) 233 ktrfaultend(result); (kgdb) print map $1 = 0xfffffe00862457a8 (kgdb) print vaddr $2 = 35020902400 (kgdb) print fault_type $3 = (kgdb) print fault_flags $4 = 0 (kgdb) print result $5 = (kgdb) up #10 0xffffffff80cf202f in trap_pfault (frame=0xffffff80dbfe2c40, usermode=1) at ../../../amd64/amd64/trap.c:762 762 rv = vm_fault(map, va, ftype, VM_FAULT_NORMAL); (kgdb) up #11 0xffffffff80cf2874 in trap (frame=0xffffff80dbfe2c40) at ../../../amd64/amd64/trap.c:363 363 i = trap_pfault(frame, TRUE); (kgdb) up #12 0xffffffff80cdb9f3 in calltrap () at ../../../amd64/amd64/exception.S:232 232 call trap Current language: auto; currently asm (kgdb) up #13 0x00000008010ac1c6 in ?? () (kgdb) up Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xffffffff80ceddcd 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577). 3572 if ((m->oflags & VPO_UNMANAGED) == 0) { 3573 newpte |= PG_MANAGED; 3574 pv = get_pv_entry(pmap, &lock); 3575 pv->pv_va = va; 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_list); 3578 if ((newpte & PG_RW) != 0) 3579 vm_page_aflag_set(m, PGA_WRITEABLE); 3580 } 3581 What additional info might I provide? -jr From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 06:28:21 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCDF3B59 for ; Mon, 9 Sep 2013 06:28:21 +0000 (UTC) (envelope-from moto@kawasaki3.org) Received: from kawasaki3.org (blackpearl.kawasaki3.org [173.230.157.78]) by mx1.freebsd.org (Postfix) with ESMTP id CA01828F3 for ; Mon, 9 Sep 2013 06:28:21 +0000 (UTC) Received: from localhost (unknown [113.157.198.194]) (Authenticated sender: moto) by kawasaki3.org (Postfix) with ESMTPSA id 64BEE1CEA9 for ; Mon, 9 Sep 2013 02:19:10 -0400 (EDT) Date: Mon, 09 Sep 2013 15:18:06 +0900 (JST) Message-Id: <20130909.151806.1420591981150797795.moto@kawasaki3.org> To: freebsd-acpi@freebsd.org Subject: Q: how to increase ACPI_MAX_TASKS From: moto kawasaki X-Mailer: Mew version 6.5 on Emacs 24.3.50 / Mule 6.0 (HANACHIRUSATO) X-Face: )._4~w!_D$r6qNS0+; nS|]WNeI4f3o)QnH[ItB[esXuc$~hQ$.,?}$SnLe/[24Hao%^q/Is 'SJtZe#21h;7z;q+iyj[^%7\46.Gg-t7.px<}L-f_:P+6i4-a{DIL[ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Mon, 09 Sep 2013 06:28:21 -0000 Hello, Could you please advice me how to increase ACPI_MAX_TASKS from 32 (default) to 64 or 128 ? (1) I am running FreeBSD 9.1-RELEASE-p6, which was updated via freebsd-update. # uname -srmv FreeBSD 9.1-RELEASE-p6 FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21 20:40:52 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 (2) Now, dmesg shows an error regarding AE_NO_MEMORY. # dmesg (snip) AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable ACPI Error: Method parse/execution failed [\\_SB_.PCI0.HEC2.HSCI] (Node 0xfffffe001d208380), AE_NO_MEMORY (20110527/psparse-560) ACPI Error: Method parse/execution failed [\\_GPE._L06] (Node 0xfffffe001d20c6c0), AE_NO_MEMORY (20110527/psparse-560) ACPI Exception: AE_NO_MEMORY, while evaluating GPE method [_L06] (20110527/evgpe-606) AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable (snip) If needed, I will show all dmesg output. please request. (3) This is because ACPI_MAX_TASKS is defined as 32 in /usr/src/sys/dev/acpica/acpivar.h ===== /* Default maximum number of tasks to enqueue. */ #ifndef ACPI_MAX_TASKS #define ACPI_MAX_TASKS 32 #endif ===== (4) When I rewrite it to 64, the error in dmesg disappeared. So far so good, but I have to re-compile the kernel in this case. If possible, I'd like to change ACPI_MAX_TASKS value by sysctl.conf or something like that. (5) /usr/src/sys/dev/acpica/Osd/OsdSchedule.c mentions debug.acpi.max_tasks. ===== /* * Allow the user to tune the maximum number of tasks we may enqueue. */ static int acpi_max_tasks = ACPI_MAX_TASKS; TUNABLE_INT("debug.acpi.max_tasks", &acpi_max_tasks); ===== But, I cannot write this sysctl tunable. That is "unknown oid". # sysctl debug.acpi.max_tasks sysctl: unknown oid 'debug.acpi.max_tasks' # sysctl -w debug.acpi.max_tasks=64 sysctl: unknown oid 'debug.acpi.max_tasks' (6) If I have to re-compile the GENERIC kernel, where should I define ACPI_MAX_TASKS ? /etc/make.conf? kernel configuration file? or acpivar.h ? Thank you very much!! Best Regards -- moto kawasaki 090-2464-8454 From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 06:57:12 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E4CACE60 for ; Mon, 9 Sep 2013 06:57:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6755D2A3E for ; Mon, 9 Sep 2013 06:57:12 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r896usAd080260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2013 15:57:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r896uqdt055461; Mon, 9 Sep 2013 15:56:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 09 Sep 2013 15:56:45 +0900 (JST) Message-Id: <20130909.155645.230313738831521270.hrs@allbsd.org> To: moto@kawasaki3.org Subject: Re: Q: how to increase ACPI_MAX_TASKS From: Hiroki Sato In-Reply-To: <20130909.151806.1420591981150797795.moto@kawasaki3.org> References: <20130909.151806.1420591981150797795.moto@kawasaki3.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Sep__9_15_56_45_2013_091)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 09 Sep 2013 15:57:04 +0900 (JST) X-Spam-Status: No, score=-90.4 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,QENCPTR1,RCVD_IN_PBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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: Mon, 09 Sep 2013 06:57:13 -0000 ----Security_Multipart(Mon_Sep__9_15_56_45_2013_091)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit moto kawasaki wrote in <20130909.151806.1420591981150797795.moto@kawasaki3.org>: mo> ===== mo> /* mo> * Allow the user to tune the maximum number of tasks we may enqueue. mo> */ mo> static int acpi_max_tasks = ACPI_MAX_TASKS; mo> TUNABLE_INT("debug.acpi.max_tasks", &acpi_max_tasks); mo> ===== mo> mo> But, I cannot write this sysctl tunable. That is "unknown oid". "TUNABLE_INT" defines a loader tunable, not a sysctl variable. To set the value, you need to enter the following line in the loader(8) prompt or put it into /boot/loader.conf: debug.acpi.max_tasks=32 mo> (6) If I have to re-compile the GENERIC kernel, where should I define mo> ACPI_MAX_TASKS ? /etc/make.conf? kernel configuration file? or mo> acpivar.h ? A kernel configuration file can include this option. The following should also work: options ACPI_MAX_TASKS=32 -- Hiroki ----Security_Multipart(Mon_Sep__9_15_56_45_2013_091)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlItcS0ACgkQTyzT2CeTzy1EpACfar1EQeHqiDs18lJx9dJKmEDc yqoAn3NzMasIAeiLGdag0r5HzOTGtUiy =fUcE -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Sep__9_15_56_45_2013_091)---- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 09:05:42 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C313918 for ; Mon, 9 Sep 2013 09:05:42 +0000 (UTC) (envelope-from moto@kawasaki3.org) Received: from kawasaki3.org (blackpearl.kawasaki3.org [173.230.157.78]) by mx1.freebsd.org (Postfix) with ESMTP id 573122136 for ; Mon, 9 Sep 2013 09:05:41 +0000 (UTC) Received: from localhost (unknown [113.157.198.194]) (Authenticated sender: moto) by kawasaki3.org (Postfix) with ESMTPSA id 719561CEA9 for ; Mon, 9 Sep 2013 05:05:41 -0400 (EDT) Date: Mon, 09 Sep 2013 18:05:30 +0900 (JST) Message-Id: <20130909.180530.1288379599737413382.moto@kawasaki3.org> To: freebsd-acpi@FreeBSD.org Subject: Re: Q: how to increase ACPI_MAX_TASKS From: moto kawasaki In-Reply-To: <20130909.155645.230313738831521270.hrs@allbsd.org> References: <20130909.151806.1420591981150797795.moto@kawasaki3.org> <20130909.155645.230313738831521270.hrs@allbsd.org> X-Mailer: Mew version 6.5 on Emacs 24.3.50 / Mule 6.0 (HANACHIRUSATO) X-Face: )._4~w!_D$r6qNS0+; nS|]WNeI4f3o)QnH[ItB[esXuc$~hQ$.,?}$SnLe/[24Hao%^q/Is 'SJtZe#21h;7z;q+iyj[^%7\46.Gg-t7.px<}L-f_:P+6i4-a{DIL[ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Mon, 09 Sep 2013 09:05:42 -0000 Dear hrs, Thank you very much for your quick and kind response as usual. Suggested setting in loader.conf works perfect for me. I cannot thank you enough!! Best Regards, -- moto kawasaki 090-2464-8454 hrs> mo> ===== hrs> mo> /* hrs> mo> * Allow the user to tune the maximum number of tasks we may enqueue. hrs> mo> */ hrs> mo> static int acpi_max_tasks = ACPI_MAX_TASKS; hrs> mo> TUNABLE_INT("debug.acpi.max_tasks", &acpi_max_tasks); hrs> mo> ===== hrs> mo> hrs> mo> But, I cannot write this sysctl tunable. That is "unknown oid". hrs> hrs> "TUNABLE_INT" defines a loader tunable, not a sysctl variable. To hrs> set the value, you need to enter the following line in the loader(8) hrs> prompt or put it into /boot/loader.conf: hrs> hrs> debug.acpi.max_tasks=32 hrs> mo> (6) If I have to re-compile the GENERIC kernel, where should I define hrs> mo> ACPI_MAX_TASKS ? /etc/make.conf? kernel configuration file? or hrs> mo> acpivar.h ? hrs> hrs> A kernel configuration file can include this option. The following hrs> should also work: hrs> hrs> options ACPI_MAX_TASKS=32 From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 11:06:43 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 77646D76 for ; Mon, 9 Sep 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 472CC29E4 for ; Mon, 9 Sep 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r89B6hpM098524 for ; Mon, 9 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r89B6gCU097819 for freebsd-acpi@FreeBSD.org; Mon, 9 Sep 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Sep 2013 11:06:42 GMT Message-Id: <201309091106.r89B6gCU097819@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 09 Sep 2013 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 17:46:04 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 997A73BD for ; Mon, 9 Sep 2013 17:46:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 734892839 for ; Mon, 9 Sep 2013 17:46:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CACFB953; Mon, 9 Sep 2013 13:46:02 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Date: Mon, 9 Sep 2013 11:22:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130908172454.15812086@shibato> In-Reply-To: <20130908172454.15812086@shibato> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309091122.30193.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Sep 2013 13:46:02 -0400 (EDT) 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: Mon, 09 Sep 2013 17:46:04 -0000 On Sunday, September 08, 2013 5:24:54 pm J.R. Oldroyd wrote: > This problem may have existed for some time in the 9.x kernel. > I've had similar panics for a while, but not had time to look into > it. I did not have this problem on 8.x kernels on this laptop. > > It never happens when the system is cold-booted. It only happens > after a suspend/resume cycle or two which is why I am posting to > freebsd-apci to start with... > > > The repeat-by goes something like this: > - boot system > - suspend system > - resume system > - use as normal (mix of email/firefox/sh & nvi/openvpn) > - perhaps suspend/resume again > - keep using as normal > - system panics, seems often to be when using firefox > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff80ceddcd > stack pointer = 0x28:0xffffff80dbfe25e0 > frame pointer = 0x28:0xffffff80dbfe2660 > 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 = 52022 (firefox) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80947986 at kdb_backtrace+0x66 > #1 0xffffffff8090d9ae at panic+0x1ce > #2 0xffffffff80cf1db0 at trap_fatal+0x290 > #3 0xffffffff80cf2111 at trap_pfault+0x211 > #4 0xffffffff80cf26c4 at trap+0x344 > #5 0xffffffff80cdb9f3 at calltrap+0x8 > #6 0xffffffff80b797a7 at vm_fault_hold+0x1b87 This is where the NULL pointer is. Frame 9 (listed below) is above this. > (kgdb) list *0xffffffff80ceddcd > 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577). > 3572 if ((m->oflags & VPO_UNMANAGED) == 0) { > 3573 newpte |= PG_MANAGED; > 3574 pv = get_pv_entry(pmap, &lock); > 3575 pv->pv_va = va; > 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); > 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_list); > 3578 if ((newpte & PG_RW) != 0) > 3579 vm_page_aflag_set(m, PGA_WRITEABLE); > 3580 } > 3581 So it seems like pv_list of a page might be busted? Can you try looking at the disassembly to see if you can find 'm' in one of the registers? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 18:57:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BDFF9E2C; Mon, 9 Sep 2013 18:57:51 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B1D02CEA; Mon, 9 Sep 2013 18:57:51 +0000 (UTC) Received: from pool-96-233-20-106.bstnma.east.verizon.net ([96.233.20.106] helo=homobox.opal.com) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VJ6ej-000Api-S1; Mon, 09 Sep 2013 18:57:50 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r89IvlOx060059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Sep 2013 14:57:47 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 96.233.20.106 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18hQTDBOxfeSBH63ktILn2K Date: Mon, 9 Sep 2013 14:57:44 -0400 From: "J.R. Oldroyd" To: John Baldwin Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Message-ID: <20130909145744.63fcba85@shibato> In-Reply-To: <201309091122.30193.jhb@freebsd.org> References: <20130908172454.15812086@shibato> <201309091122.30193.jhb@freebsd.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/EUJJhy2sFqpOzmZwydjaLl0"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Mon, 09 Sep 2013 14:57:48 -0400 (EDT) X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, RP_MATCHES_RCVD shortcircuit=no autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com 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: Mon, 09 Sep 2013 18:57:51 -0000 --Sig_/EUJJhy2sFqpOzmZwydjaLl0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 9 Sep 2013 11:22:29 -0400 John Baldwin wrote: > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x0 > > fault code =3D supervisor write data, page not present > > instruction pointer =3D 0x20:0xffffffff80ceddcd > > stack pointer =3D 0x28:0xffffff80dbfe25e0 > > frame pointer =3D 0x28:0xffffff80dbfe2660 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 52022 (firefox) > > trap number =3D 12 > > panic: page fault > > cpuid =3D 0 > > KDB: stack backtrace: > > #0 0xffffffff80947986 at kdb_backtrace+0x66 > > #1 0xffffffff8090d9ae at panic+0x1ce > > #2 0xffffffff80cf1db0 at trap_fatal+0x290 > > #3 0xffffffff80cf2111 at trap_pfault+0x211 > > #4 0xffffffff80cf26c4 at trap+0x344 > > #5 0xffffffff80cdb9f3 at calltrap+0x8 > > #6 0xffffffff80b797a7 at vm_fault_hold+0x1b87 >=20 > This is where the NULL pointer is. Frame 9 (listed below) is above this. >=20 > > (kgdb) list *0xffffffff80ceddcd > > 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577). > > 3572 if ((m->oflags & VPO_UNMANAGED) =3D=3D 0) { > > 3573 newpte |=3D PG_MANAGED; > > 3574 pv =3D get_pv_entry(pmap, &lock); > > 3575 pv->pv_va =3D va; > > 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); > > 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_list); > > 3578 if ((newpte & PG_RW) !=3D 0) > > 3579 vm_page_aflag_set(m, PGA_WRITEABLE); > > 3580 } > > 3581 >=20 > So it seems like pv_list of a page might be busted? Can you try looking = at > the disassembly to see if you can find 'm' in one of the registers? >=20 Sure, here you go... (kgdb) print m $1 =3D 0xfffffe00b260b430 (kgdb) print m->md.pv_list $4 =3D {tqh_first =3D 0x0, tqh_last =3D 0x0} (kgdb) print pv $2 =3D 0xfffffe0095088ad8 (kgdb) print pv_list No symbol "pv_list" in current context. (kgdb) info registers rax 0x1 1 rbx 0xfffffe0095088ae0 -2196522890528 rcx 0x0 0 rdx 0xfffffe00b260b430 -2196030573520 rsi 0x0 0 rdi 0x153 339 rbp 0xffffff80dbfe2660 0xffffff80dbfe2660 rsp 0xffffff80dbfe25f0 0xffffff80dbfe25f0 r8 0x0 0 r9 0x827689000 35020902400 r10 0x63 99 r11 0xfffffe00b260b430 -2196030573520 r12 0x47f 1151 r13 0xfffffe00862458d8 -2196772726568 r14 0xfffffe0092907448 -2196564315064 r15 0xfffffe0095088ad8 -2196522890536 rip 0xffffffff80ceddcd 0xffffffff80ceddcd eflags 0x10202 66050 cs 0x20 32 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 --Sig_/EUJJhy2sFqpOzmZwydjaLl0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEUEARECAAYFAlIuGisACgkQls33urr0k4mOdgCdGKN1VVwYKDEe9z0s7mFQRpXH fc8AmJ07mKw+RsSBOSvfoKoldf8zWWU= =XhJe -----END PGP SIGNATURE----- --Sig_/EUJJhy2sFqpOzmZwydjaLl0-- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 9 21:16:38 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A584591D for ; Mon, 9 Sep 2013 21:16:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F92324C8 for ; Mon, 9 Sep 2013 21:16:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93493B953; Mon, 9 Sep 2013 17:16:36 -0400 (EDT) From: John Baldwin To: "J.R. Oldroyd" Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Date: Mon, 9 Sep 2013 16:54:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130908172454.15812086@shibato> <201309091122.30193.jhb@freebsd.org> <20130909145744.63fcba85@shibato> In-Reply-To: <20130909145744.63fcba85@shibato> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201309091654.27160.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Sep 2013 17:16:36 -0400 (EDT) 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: Mon, 09 Sep 2013 21:16:38 -0000 On Monday, September 09, 2013 2:57:44 pm J.R. Oldroyd wrote: > On Mon, 9 Sep 2013 11:22:29 -0400 John Baldwin wrote: > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x0 > > > fault code = supervisor write data, page not present > > > instruction pointer = 0x20:0xffffffff80ceddcd > > > stack pointer = 0x28:0xffffff80dbfe25e0 > > > frame pointer = 0x28:0xffffff80dbfe2660 > > > 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 = 52022 (firefox) > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > KDB: stack backtrace: > > > #0 0xffffffff80947986 at kdb_backtrace+0x66 > > > #1 0xffffffff8090d9ae at panic+0x1ce > > > #2 0xffffffff80cf1db0 at trap_fatal+0x290 > > > #3 0xffffffff80cf2111 at trap_pfault+0x211 > > > #4 0xffffffff80cf26c4 at trap+0x344 > > > #5 0xffffffff80cdb9f3 at calltrap+0x8 > > > #6 0xffffffff80b797a7 at vm_fault_hold+0x1b87 > > > > This is where the NULL pointer is. Frame 9 (listed below) is above this. > > > > > (kgdb) list *0xffffffff80ceddcd > > > 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577). > > > 3572 if ((m->oflags & VPO_UNMANAGED) == 0) { > > > 3573 newpte |= PG_MANAGED; > > > 3574 pv = get_pv_entry(pmap, &lock); > > > 3575 pv->pv_va = va; > > > 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); > > > 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_list); > > > 3578 if ((newpte & PG_RW) != 0) > > > 3579 vm_page_aflag_set(m, PGA_WRITEABLE); > > > 3580 } > > > 3581 > > > > So it seems like pv_list of a page might be busted? Can you try looking at > > the disassembly to see if you can find 'm' in one of the registers? > > > > Sure, here you go... > > (kgdb) print m > $1 = 0xfffffe00b260b430 > (kgdb) print m->md.pv_list > $4 = {tqh_first = 0x0, tqh_last = 0x0} Eh, tqh_last shouldn't be NULL here IIRC. I think it should point at &tqh_first. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 11 15:55:00 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B30EC306 for ; Wed, 11 Sep 2013 15:55:00 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37F2F2545 for ; Wed, 11 Sep 2013 15:55:00 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so4719026eak.4 for ; Wed, 11 Sep 2013 08:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vH7gAHrpA/3F+BHjDmLzT7M4kXGpPmp8vl5oaARBG7s=; b=XXx1XbUrZq1BJeyzrt1hCXyI2da/f1a8vUQlQBkrFeaoBJJGeKqjoB/biRoOC7+CjM AScDJBXuwageTeB3dyhTzGM7ULOEoE3Udfs91opWnZ01SXoRXKiSU660dyoOKHZczoXm Wuh/cRLSAUOD15/+Q7IwKf38RvT/urE0Qm6J476ne9G63/Jh9yuby/O1VS3BxkfXV/li RAiY5mliX9pyncRhKBLD5UGO0jMGESWvw3rZCp2shd1xT4n5aoJxoC0qdvw91MpPbIDa 8RToA3uP/zuMnv/1CeUEvQ65Ab7u1yn8mg1qFhrTG5Of/k0QF2WN/uynbPwtXw3C5QzW ySZw== MIME-Version: 1.0 X-Received: by 10.14.210.195 with SMTP id u43mr3241388eeo.80.1378914898533; Wed, 11 Sep 2013 08:54:58 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Wed, 11 Sep 2013 08:54:58 -0700 (PDT) Date: Wed, 11 Sep 2013 08:54:58 -0700 Message-ID: Subject: ACPI warning messages on boot-up From: hiren panchasara To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Wed, 11 Sep 2013 15:55:00 -0000 I have lenovo T420 that is showing acpi warnings on bootup after recent upgrade. % uname -a FreeBSD flymockour-l7.corp.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r255423M: Mon Sep 9 12:29:22 PDT 2013 root@flymockour-l7.corp.yahoo.com:/usr/obj/usr/home/hirenp/head/sys/GENERIC amd64 (ignore M in the rev number, nothing related) warnings: ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) Are these harmful? % sysctl -a | grep acpi | grep version debug.acpi.acpi_ca_version: 20130823 A funny thing I've noticed after this upgrade is, the laptop shuts down after getting overheated. That happened twice in last 2 days. I keep my laptop on almost all the time. I am not sure if the cooling is not working properly after the upgrade or what. - just a suspicion. (Might just have to open it up and remove some dust) % sysctl -a| grep -i acpi | grep thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 63.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 98.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 Cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 13 01:23:53 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05A5B3DA; Fri, 13 Sep 2013 01:23:53 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C8D922C43; Fri, 13 Sep 2013 01:23:52 +0000 (UTC) Received: from pool-96-233-20-106.bstnma.east.verizon.net ([96.233.20.106] helo=homobox.opal.com) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VKI6w-000EmP-Ee; Fri, 13 Sep 2013 01:23:50 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r8D1Nlo5051133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Sep 2013 21:23:47 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 96.233.20.106 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Hf2gtU3/AWfXDQgZLi6oy Date: Thu, 12 Sep 2013 21:23:39 -0400 From: "J.R. Oldroyd" To: John Baldwin Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Message-ID: <20130912212339.3b446e73@shibato> In-Reply-To: <201309091654.27160.jhb@freebsd.org> References: <20130908172454.15812086@shibato> <201309091122.30193.jhb@freebsd.org> <20130909145744.63fcba85@shibato> <201309091654.27160.jhb@freebsd.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/91/B65Hd0S1PoDOMY+KL+UI"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Thu, 12 Sep 2013 21:23:48 -0400 (EDT) X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, RP_MATCHES_RCVD shortcircuit=no autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com 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: Fri, 13 Sep 2013 01:23:53 -0000 --Sig_/91/B65Hd0S1PoDOMY+KL+UI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 9 Sep 2013 16:54:27 -0400 John Baldwin wrote: > > > >=20 > > > > (kgdb) list *0xffffffff80ceddcd > > > > 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:35= 77). > > > > 3572 if ((m->oflags & VPO_UNMANAGED) =3D=3D 0) { > > > > 3573 newpte |=3D PG_MANAGED; > > > > 3574 pv =3D get_pv_entry(pmap, &lock); > > > > 3575 pv->pv_va =3D va; > > > > 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); > > > > 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_li= st); > > > > 3578 if ((newpte & PG_RW) !=3D 0) > > > > 3579 vm_page_aflag_set(m, PGA_WRITEABLE); > > > > 3580 } > > > > 3581 > > >=20 > > > So it seems like pv_list of a page might be busted? Can you try look= ing at > > > the disassembly to see if you can find 'm' in one of the registers? > > >=20 > >=20 > > Sure, here you go... > >=20 > > (kgdb) print m > > $1 =3D 0xfffffe00b260b430 > > (kgdb) print m->md.pv_list > > $4 =3D {tqh_first =3D 0x0, tqh_last =3D 0x0} >=20 > Eh, tqh_last shouldn't bmd.pv_liste NULL here IIRC. I think it should po= int at > &tqh_first. >=20 I had a quick look at the code for this list. md.pv_list is initialized in pmap_page_init() and there's also a similar piece of init in pmap_init(), both in sys/amd64/amd64/pmap.c and also in the other arch's. But I have little background on how the VM code is supposed to be initialized or saved on suspend and re-inited on resume. It'd take me ages to work out what should be going on here. What's the best course of action here...? Open a PR and hand-over to someone with more background in these areas? -jr --Sig_/91/B65Hd0S1PoDOMY+KL+UI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlIyaSMACgkQls33urr0k4ls0QCfSUJTi9q9e/wQ75c1/O/zIZ7z X/UAni1PblYvBGhADL10hR6VSX8Vjif1 =0zVN -----END PGP SIGNATURE----- --Sig_/91/B65Hd0S1PoDOMY+KL+UI-- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 13 15:26:16 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 65203A23 for ; Fri, 13 Sep 2013 15:26:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D9C42935 for ; Fri, 13 Sep 2013 15:26:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4021FB94F; Fri, 13 Sep 2013 11:26:15 -0400 (EDT) From: John Baldwin To: "J.R. Oldroyd" Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Date: Fri, 13 Sep 2013 10:36:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130908172454.15812086@shibato> <201309091654.27160.jhb@freebsd.org> <20130912212339.3b446e73@shibato> In-Reply-To: <20130912212339.3b446e73@shibato> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201309131036.24554.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Sep 2013 11:26:15 -0400 (EDT) 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: Fri, 13 Sep 2013 15:26:16 -0000 On Thursday, September 12, 2013 9:23:39 pm J.R. Oldroyd wrote: > On Mon, 9 Sep 2013 16:54:27 -0400 John Baldwin wrote: > > > > > > > > > > > (kgdb) list *0xffffffff80ceddcd > > > > > 0xffffffff80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577). > > > > > 3572 if ((m->oflags & VPO_UNMANAGED) == 0) { > > > > > 3573 newpte |= PG_MANAGED; > > > > > 3574 pv = get_pv_entry(pmap, &lock); > > > > > 3575 pv->pv_va = va; > > > > > 3576 CHANGE_PV_LIST_LOCK_TO_PHYS(&lock, pa); > > > > > 3577 TAILQ_INSERT_TAIL(&m->md.pv_list, pv, pv_list); > > > > > 3578 if ((newpte & PG_RW) != 0) > > > > > 3579 vm_page_aflag_set(m, PGA_WRITEABLE); > > > > > 3580 } > > > > > 3581 > > > > > > > > So it seems like pv_list of a page might be busted? Can you try looking at > > > > the disassembly to see if you can find 'm' in one of the registers? > > > > > > > > > > Sure, here you go... > > > > > > (kgdb) print m > > > $1 = 0xfffffe00b260b430 > > > (kgdb) print m->md.pv_list > > > $4 = {tqh_first = 0x0, tqh_last = 0x0} > > > > Eh, tqh_last shouldn't bmd.pv_liste NULL here IIRC. I think it should point at > > &tqh_first. > > > > I had a quick look at the code for this list. > > md.pv_list is initialized in pmap_page_init() and there's also a > similar piece of init in pmap_init(), both in sys/amd64/amd64/pmap.c > and also in the other arch's. > > But I have little background on how the VM code is supposed to be > initialized or saved on suspend and re-inited on resume. It'd take > me ages to work out what should be going on here. The hardware should preserve RAM contents which is all VM really needs. > What's the best course of action here...? Open a PR and hand-over to > someone with more background in these areas? I think kib@ is the best person to ask. I suspect it is a bug in how a driver is handling resume perhaps. -- John Baldwin