[Top] [All Lists]

Re: Strange, strange occurence

To: "S C" <>, "Ralf Baechle" <>
Subject: Re: Strange, strange occurence
From: "Kevin D. Kissell" <>
Date: Mon, 12 Jul 2004 23:48:31 +0200
Cc: <>
Original-recipient: rfc822;
References: <>
> And thinking about it a little more, I might as well clarfy my understanding 
> while we're on the topic.
> Here's a code snippet from r4k_tlb_init() in arch/mips/mm/c-r4k.c
> memcpy((void *)KSEG0, &except_vec0_r4000, 0x80);
> flush_icache_range(KSEG0, KSEG0 + 0x80);
> So my understanding is that the TLB exception handler is being copied to the 
> right memory location, and just in case some other TLB exception handler 
> (YAMON's presumably) is residing in I-cache, to flush ( hit invalidate) it. 
> Is this correct?
> Shouldn't there be code to writeback_invalidate the exception handler from 
> the data cache ? Presumably the memcpy causes the TLB handler to lodge 
> itself in the D cache till it is moved to RAM (either explicitly or when 
> some other lines replace the cache lines where the handler is), right?
> Thanks in advance for helping me understand the issue here.

Your intuition is correct, and the code in r4k_tlb_init() does look scary.
But at least in the linux-mips CVS tree, flush_icache_range() tests to see
if "cpu_has_ic_fills_f_dc" (CPU has Icache fills from Dcache, I presume)
is set, and if it isn't, it pushes the specified range out of the Dcache before
flushing the Icache.  I would speculate that either your c-r4k.c is out of
sync with yout tlb-r4k.c, or you erroneously have cpu_has_ic_fills_f_dc


            Kevin K.

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