linux-mips
[Top] [All Lists]

possible Malta 4Kc cache problem ...

To: linux-mips@linux-mips.org
Subject: possible Malta 4Kc cache problem ...
From: Jun Sun <jsun@mvista.com>
Date: Tue, 3 Dec 2002 22:45:04 -0800
Cc: jsun@mvista.com
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5i
I attached the test case.  Untar it.  Type 'make' and run 'a.out'.

If the test fails you will see a print-out.  Otherwise you see nothing.

It does not always fail.  But if it fails, it is usually pretty consistent.
Try a few times.  Moving source tree to a different directory may cause
the symptom appear or disappear.

I spent quite some time to trace this problem, and came to suspect
there might be a hardware problem.

The problem involves emulating a "lw" instruction in cp1 branch delay
slot, which needs to  set up trampoline in user stack.  The net effect
looks as if the icache line or dcache line is not flushed properly.

Using gdb/kgdb, printf or printk in any useful places would hide the bug.

I did find a smaller part of the problem.  flush_cache_sigtramp for
MIPS32 (4Kc) calls protected_writeback_dcache_line in mips32_cache.h.
It uses Hit_Writeback_D, and the 4Kc mannual says it is not implemented
and executed as no-op (*ick*).

Even after fixing this, I still see the problem happening.

If you replace flush_cache_sigtramp() with flush_cache_all(), symptom
would disppear.

Several of my tests seem to suggest it is the icache that did not
get flushed (or updated) properly.

Not re-producible on other MIPS boards.  At least so far.

Does anybody with more knowledge about 4Kc have any clues here?

Thanks.

Jun

Attachment: fp_java.tar.gz
Description: application/tar-gz

<Prev in Thread] Current Thread [Next in Thread>