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