At 09:10 AM 11/7/2001 -0800, Chuck Silvers wrote:
>ah, I was wrong, it is a pmap bug.  pmap_pte_clear() is calling
>TLBIE() on the address that contains the PTE rather than the address
>that the PTE is mapping.  the attached diff fixes the problem.

That's intentional.  When only updating the R/C bits of the PTE,
the PPC 32-bit Programming Environment Manual.

>I don't know what document that reference about "As shown in Section 
>7.6.3.2.2"
>comes from, is that document wrong or did you just mis-read it, matt?

I doubt it's wrong.  Hmmm.  that sequence is only value for the REF
bit, not the CHG bit.  I think I need to think about this more.

Reading a bit closer, I think I need some lwarx/stwcx. instructions
when directly manipulating the PPC PTEs in order to garuantee
consistency of the REF|CHG bits as I read them:

To modify the WIMG or PP bits without overwriting an R or C bit update 
being performed
by the processor, a sequence similar to the one shown above can be used, 
except that the
second line is replaced by a loop containing an lwarx/stwcx. instruction 
pair that emulates
an atomic compare and swap of the low-order word of the PTE.

>also, pmap_clear_bit() is doing some unnecessary work to compute
>the pte's address, it could just check the PTE_VALID bit in the pvo's
>copy of the pte and skip the pte processing if it's not set.

True.