From owner-freebsd-alpha Thu Jun 14 11: 2:17 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0A2AD37B405; Thu, 14 Jun 2001 11:02:00 -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.9.3/8.9.3) with ESMTP id OAA10031; Thu, 14 Jun 2001 14:01:59 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f5EI1TU22008; Thu, 14 Jun 2001 14:01:29 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15144.64505.439116.166985@grasshopper.cs.duke.edu> Date: Thu, 14 Jun 2001 14:01:29 -0400 (EDT) To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org Subject: RE: alpha pmap corruption continues In-Reply-To: References: <15144.55776.3763.28141@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Baldwin writes: > > On 14-Jun-01 Andrew Gallatin wrote: > > > > fatal kernel trap: > > > > trap entry = 0x2 (memory management fault) > > cpuid = 0 > > faulting va = 0xfffffffe00480210 > > Interesting faulting address. This is in K0SEG isn't it? :( No, K0SEG goes from 0xfffffc0000000000LL to 0xfffffdffffffffffLL Anything with a 0xf..ffe00... is mapped (kernel) memory. <...> > In vm_fault() we check to see if we already own the vm_mtx to prevent recursing > on it. Look at the hadvmlock variable in vm_fault(). That means, though, that > it shouldn't be reporting vm_map.c as it's last acquired line though. :( Oh. > This is due to interlock ugliness. When we grab a vm_map lock, we temporarily > release the vm lock during the lock acquisition adn then reacquire it. So, what are the odds that there's a race somewhere in this releasing & reacquireing? We used to be at splvm throughout this code, right? Is this at a point where we used to sleep (or otherwise drop to ipl0?), or is this a new opportunity for a race? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message