John David Anglin wrote: > Having looked at the code a bit, I have come to the conclusion that the > problem is not with the sr3 value. In all debugging I added I could _always_ see that sr3 had the wrong values. cr8 and mm->context were always correct. Interestingly it was often just a few numbers off in the lower 4 bits, e.g. sr3 should have been 0x1a8 but was 0x1a2 (just an example). > We have a one-to-one mapping between > space register values and protection IDs. TLB entries get inserted using > the space register value for the protection ID (see entry.S). So, I think > we have to have inconsistent values in cr8 and sr3. Again, only sr3 is wrong. cr8 is correct. > I think the bug may be in flush_user_cache_page_non_current. It hijacks > sr3 temporarily and I don't think cr8 is updated when this is done. The > switch may need to be atomic. I tried that as well, e.g. adding local_irq_[en|dis]able didn't worked (it crashed IIRC). Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
