Re: "pmap_unwire: wiring ... didn't change!"
Chuck Silvers <chuq <at> chuq.com>
2005-04-30 22:33:32 GMT
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.