panic after acpi suspend/resume 9.1, 9.2rc3

[John Baldwin]

On Monday, September 09, 2013 2:57:44 pm J.R. Oldroyd wrote:
> On Mon, 9 Sep 2013 11:22:29 -0400 John Baldwin <jhb at freebsd.org> 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