Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2001 10:48:07 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-alpha@FreeBSD.org, alfred@FreeBSD.org
Subject:   RE: alpha pmap corruption continues
Message-ID:  <XFMail.010614104807.jhb@FreeBSD.org>
In-Reply-To: <15144.55776.3763.28141@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

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>
> <t0=0x90042,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 <jhb@FreeBSD.org> -- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010614104807.jhb>