From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 16 07:41:31 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F67D16A4CE; Fri, 16 Apr 2004 07:41:31 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85CBF43D39; Fri, 16 Apr 2004 07:41:30 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i3GEfRFC018300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Apr 2004 10:41:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i3GEfM65063897; Fri, 16 Apr 2004 10:41:22 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16511.61586.123216.627307@grasshopper.cs.duke.edu> Date: Fri, 16 Apr 2004 10:41:22 -0400 (EDT) To: "Alan L. Cox" In-Reply-To: <407F775D.7020908@imimic.com> References: <20040411093343.GA89809@xor.obsecurity.org> <200404132236.20792.jhb@FreeBSD.org> <16509.42895.49213.222503@grasshopper.cs.duke.edu> <20040416045453.GA78366@xor.obsecurity.org> <407F68BA.6000405@imimic.com> <20040416053930.GA78940@xor.obsecurity.org> <20040416054340.GZ238@cs.rice.edu> <20040416054804.GA79165@xor.obsecurity.org> <407F775D.7020908@imimic.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: alc@FreeBSD.org cc: alpha@FreeBSD.org cc: Alan Cox cc: Andrew Gallatin cc: Kris Kennaway Subject: Re: Another alpha panic X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2004 14:41:31 -0000 Alan L. Cox writes: > Kris Kennaway wrote: > > > > Dump of assembler code for function pmap_activate: > > 0xfffffc00005cf0b0 : ldah gp,14(t12) > ... > > 0xfffffc00005cf160 : srl t1,0xd,t1 > > 0xfffffc00005cf164 : stq t1,16(t2) > ... > I believe that the shift right is the "... >> PAGE_SHIFT" in > > td->td_pcb->pcb_hw.apcb_ptbr = > ALPHA_K0SEG_TO_PHYS((vm_offset_t) pmap->pm_lev1) >> PAGE_SHIFT; > > and the store quad is dereferencing "td->td_pcb". In other words, > td->td_pcb points to never-never land. > Is it really pointing into never-never land? The original panic was that pmap_emulate_reference() was complaining that the page was not managed.. The physical address 0xb0a0000 is not totally unreasonable, and would sit around ~176MB into memory. The fact that the trap was an ALPHA_MMCSR_FOW, and not an ALPHA_MMCSR_INVALTRANS or ALPHA_MMCSR_ACCESS makes me think that the kva was also good... I was wondering if there might be some more insidious pmap corruption happening. Or at least why a page in the middle of memory is not marked as managed. Drew