From owner-freebsd-alpha Thu Jun 14 10:48:42 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 1CB1137B401; Thu, 14 Jun 2001 10:48:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5EHm3165032; Thu, 14 Jun 2001 10:48:03 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15144.55776.3763.28141@grasshopper.cs.duke.edu> Date: Thu, 14 Jun 2001 10:48:07 -0700 (PDT) From: John Baldwin To: Andrew Gallatin Subject: RE: alpha pmap corruption continues Cc: freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org 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 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? :( > Stopped at pmap_remove_pages+0xa8: ldl t0,0(t2) <0xfffffffe00480210> > > db> tr > pmap_remove_pages() at pmap_remove_pages+0xa8 > exit1() at exit1+0xab8 > sys_exit() at sys_exit+0x24 > syscall() at syscall+0x628 > XentSys() at XentSys+0x64 > --- syscall (1, FreeBSD ELF, sys_exit) --- > --- user mode --- > > db> show locks > exclusive (sleep mutex) vm (0xfffffc00007be0f8) locked @ > ../../vm/vm_map.c:2617 > exclusive (sleep mutex) Giant (0xfffffc00007bed90) locked @ > ../../vm/vm_fault.c:213 > db> show pcpu > cpuid = 0 > ipis = 0 > next ASN = 148 > curproc = 0xfffffe00069bff80: pid 18853 "make" > curpcb = 0x66fc000 > fpcurproc = none > idleproc = 0xfffffe000589f600: pid 10 "idle: cpu0" > spin locks held: > db> e vm_faults_no_vm_mtx > vm_faults_no_vm_mtx: b7c70 > db> e vm_faults_no_giant > vm_faults_no_giant: 0 > db> > > > So.. maybe this is a dumb question, but it looks like the vm_mtx was > locked in vm_map_lookup as part of the vm fault path. But, it SHOULD > have gotten locked in exit1(), around pmap_remove_pages, shouldn't it? So, > shouldn't there have been a lock-recursion message in there? 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. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message