>
> Yep, just that now its the ptraceing process which is faulting in the
> page,
> instead of the (ptraced) process itself.
>
> So Anton, can you move the _tlbie() call up to
>
> && !test_bit(PG_arch_1, &page->flags)) {
> <---------- HERE
> if (vma->vm_mm == current->active_mm)
> __flush_dcache_icache((void *) address);
> else
> flush_dcache_icache_page(page);
> set_bit(PG_arch_1, &page->flags);
>
> So that it covers both cases instead of just (vma->vm_mm ==
> current->active_mm) ?
>
> Its safe to do it because the address space ID is ignored by tlbie
> accordingly
> to the manual page:
>
> The ASID value in the entry is ignored for the purpose of
> matching an invalidate address, thus multiple entries can be invalidated
> if they have the same effective address and different ASID values.
Well, unfortunately, that doesn't work :(. If i'm right, the
__flush_dcache_icache((void *) address) should avoid that the cache says
faulting address again.
The flush_dcache_icache_page(page) should flush the cache, where stands,
page not mapped. but the flush_dcache_icache_page(page) oopses on my system.
but instead of this call, the call __flush_dcache_icache(page_address(page))
works. for me, that also makes more sence. and also, the
flush_dcache_icache_page(page) calls the flush_dcache_icache_phys, which
turns off the data virtual address mapping. i found that a bit strange. any
comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050715/5a6ed5a4/attachment.htm
