Date: Mon, 9 Sep 2013 11:22:29 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Message-ID: <201309091122.30193.jhb@freebsd.org> In-Reply-To: <20130908172454.15812086@shibato> References: <20130908172454.15812086@shibato>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201309091122.30193.jhb>