hi again,

I checked in the #2 approach from below earlier today.
I'll request pullups to release branches in a few days
if no one reports any problems.

-Chuck


On Sat, Feb 12, 2005 at 04:32:47PM -0800, Chuck Silvers wrote:
> hi,
> 
> I looked into the "pmap_unwire: wiring ... didn't change!" problem.
> what's happening is that sometimes we're going through uvm_fault() again
> for one of the wired pages, and the pmap_enter() which results from that
> replaces the wired pmap entry with non-wired one.  so why would we go through
> uvm_fault() again?  that's happening because sometimes the TLB entry is
> recycled after the page mapped by one side of the entry is wired and before
> the other page is wired.  and when MachTLBUpdate() is called for the second
> page, the entry it creates only has the second side filled in.  this causes
> us to get a "TLB invalid" trap when we access the other half of the TLB entry
> instead of the "TLB miss" trap that we would get if there were no TLB entry
> at all.  the handler for "TLB invalid" traps from usermode always calls
> trap() instead of looking at the PTEs.
> 
> so the problem is that the PTEs and the TLB get out of sync, and the trap
> handlers aren't expecting that.  I see several possible fixes, in
> approximate decreasing order of preference:
> 
>  - change MachTLBUpdate() to take both PTEs for the TLB entry for MIPS3.
> 
>  - change the MIPS3 MachTLBUpdate() to only update existing TLB entries,
>    not create new ones.
> 
>  - have the MIPS3 user "TLB invalid" trap handler try to reload from the
>    PTEs before calling trap().
> 
>  - use MIPS3_TBIS() instead of MachTLBUpdate() for user mappings on MIPS3.
> 
> 
> the last one was the easiest, so I implemented that one and it appears to
> make the problem go away.  the patch is attached.  does anyone want to
> implement one of the better solutions soon?  if not, I'll just check in
> what I've got (after updating it to be friendly to MIPS1, etc).
> 
> -Chuck