> Date: Fri, 21 Jun 1996 00:19:21 -0400
> From: Michael Richardson <mcr@sandelman.ocunix.on.ca>

>   I rebuilt tonight to enable mmap debugging back in so I could see
> when the shared libraries were being sucked in...
>   I had sup'ed on Tuesday night (I think). I started running the
> kernel tonight. MUCH more stable from the point of view of shared
> libraries. It has been compiling tcl, cyrus and kerberos for some
> time. (Actually KRB4 from MIT runs into problems configuring. Isn't
> krb4 already part of the dist? But it doesn't come with servers I
> think...)
> 
>   I get:
> 
> amaterasu-[/sandel/lib/xemacs-19.12] 44 >pmap_fault_reload: wrong context
> Stopped at      _Debugger+0x6:  unlk    a6
> db> 
> 
>   Hmm. What does this mean? I do not think that pmap.c got updated in
> that sup...

Oh my gosh!  That's terrible!  That means the fault handler was
about to resolve a fault by inserting a new mapping in the WRONG
context!  That test indicates there may be a bug in getting the
MMU context switched at the appropriat times.

By the way, I've been thinking of doing MMU context switches
a little differently (sort of "on demand") which might help
to avoid this problem.  For now, though, you might look at the
#ifdef CONTEXT_DEBUG code.  I'm not sure it still does anything
useful, but you could always fix it up.  That may help identify
what is forgetting to set the correct MMU context...

>   If I continue things seem okay...
Surprising.  It should have had incorrect mappings at that point.

>   If it matters I was single stepping in GDB.

Maybe this is related to ptrace, which needs to poke things in
the VM context of some OTHER process (which implies temporarily
switching the MMU context to the OTHER process and restoring).

Gordon