Subject: Re: "pmap_unwire: wiring ... didn't change!"
To: None <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 04/30/2005 15:33:32
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.
On Sat, Feb 12, 2005 at 04:32:47PM -0800, Chuck Silvers wrote:
> 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).