On Wed, Feb 09, 2005 at 09:06:42AM +0100, Rojhalat Ibrahim wrote:
> Ok, thanks. If I can try anything that might help track down
> the problem, please let me know.
Try this patch which is meant to be used in combination with the previous
patch. It moves a test which determines if we actually need to perform a
cacheflush to the right place. That's a bug which is harmless on UP but
a severe bug on SMP.
c-r4k.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
--- linux-sgi-ip27-ua.orig/arch/mips/mm/c-r4k.c 2005-02-10 14:25:54.935572026
+++ linux-sgi-ip27-ua/arch/mips/mm/c-r4k.c 2005-02-10 14:28:02.329527242
@@ -376,6 +376,13 @@
+ * If ownes no valid ASID yet, cannot possibly have gotten
+ * this page into the cache.
+ if (cpu_context(smp_processor_id(), vma->vm_mm) == 0)
page &= PAGE_MASK;
pgdp = pgd_offset(mm, page);
pudp = pud_offset(pgdp, page);
@@ -433,13 +440,6 @@
struct flush_cache_page_args args;
- * If ownes no valid ASID yet, cannot possibly have gotten
- * this page into the cache.
- if (cpu_context(smp_processor_id(), vma->vm_mm) == 0)
args.vma = vma;
args.page = page;