linux-mips-fnet
[Top] [All Lists]

Re: bug in the latest cache code?

To: jsun@mvista.com
Subject: Re: bug in the latest cache code?
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date: Thu, 10 Aug 2000 11:30:36 +0900
Cc: linux@engr.sgi.com, linux-mips@fnet.fr
In-reply-to: <3992007C.49050FC@mvista.com>
Organization: TOSHIBA Personal Computer System Corporation
References: <3992007C.49050FC@mvista.com>
>>>>> On Wed, 09 Aug 2000 18:08:12 -0700, Jun Sun <jsun@mvista.com> said:
jsun> A new function, r4k_flush_icache_page_i32(), was added recently.
jsun> It calls blast_icache32_page(), which uses Hit cache operations
jsun> to flush cache.  Unfortunately, that will generate TLB fault if
jsun> virtual address is not present in TLB.  Under certain
jsun> conditions, r4k_flush_icache_page_i32() will be called in the
jsun> middle of handling a page fault, and it will then generate the
jsun> same page fault again with cache hit operation.  This causes a
jsun> deadlock (on current->mm->mmap_sem).

To my knowlege, if the vierual address is not present in TLB, cache
hit operation generates TLB refill exception, not TLB invalid
exception.  After the TLB refill excepsion, the cache instruction can
continue execution without a page fault (no deadlock).

I met the same deadlock problem on my r3k (with r4k-like cache) board
with 2.2.12 based kernel.  I doubted my TLB/cache codes first, but the
real cause was in vt.c.  _kd_mksound() modifies TLB refill handler
code if mips_io_port_base == 0xa0000000.  Modifing the #if-line near
_kd_mksound() fixed my problem.

Hope this helps.

---
Atsushi Nemoto

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