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.
Thanks,
Ralf
c-r4k.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-sgi-ip27-ua/arch/mips/mm/c-r4k.c
===================================================================
--- linux-sgi-ip27-ua.orig/arch/mips/mm/c-r4k.c 2005-02-10 14:25:54.935572026 +0100
+++ linux-sgi-ip27-ua/arch/mips/mm/c-r4k.c 2005-02-10 14:28:02.329527242 +0100
@@ -376,6 +376,13 @@
pmd_t *pmdp;
pte_t *ptep;
+ /*
+ * 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)
+ return;
+
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)
- return;
-
args.vma = vma;
args.page = page;
