Date: Thu, 14 Jun 2001 14:01:29 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org Subject: RE: alpha pmap corruption continues Message-ID: <15144.64505.439116.166985@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.010614104807.jhb@FreeBSD.org> References: <15144.55776.3763.28141@grasshopper.cs.duke.edu> <XFMail.010614104807.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15144.64505.439116.166985>