Date: Fri, 13 Sep 2013 10:36:24 -0400 From: John Baldwin <jhb@freebsd.org> To: "J.R. Oldroyd" <fbsd@opal.com> Cc: freebsd-acpi@freebsd.org Subject: Re: panic after acpi suspend/resume 9.1, 9.2rc3 Message-ID: <201309131036.24554.jhb@freebsd.org> In-Reply-To: <20130912212339.3b446e73@shibato> References: <20130908172454.15812086@shibato> <201309091654.27160.jhb@freebsd.org> <20130912212339.3b446e73@shibato>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, September 12, 2013 9:23:39 pm J.R. Oldroyd wrote:
> On Mon, 9 Sep 2013 16:54:27 -0400 John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201309131036.24554.jhb>