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