Subject: Re: Strange, strange occurence

From: "S C" <[email-masked]>
Date: Mon, 12 Jul 2004 20:49:10 +0000

Hi Niels, Ralf, Kevin

Thanks for responding to my query! For the moment, I have fixed the 
symptoms, but still don't know what the problem is (it could be what you 
guys suspect it to be). The r4k_flush_icache_range() was being called from 
inside r4k_tlb_init() and the range being specified was KSEG0 to KSEG0 + 
0x80, i.e. the TLB handler. I commented out the call to 
r4k_flush_icache_range and now the kernel seems to boot normally! But I 
suspect I have not fixed a problem, merely sidestepped it.

So now maybe I should repeat the question Niels asked: why was that call 
necessary?

Thanks again,
-Steve.

>From: Ralf Baechle <[email-masked]>
>To: S C <[email-masked]>
>CC: [email-masked]
>Subject: Re: Strange, strange occurence
>Date: Sat, 10 Jul 2004 12:04:12 +0200
>
>On Fri, Jul 09, 2004 at 06:50:00PM +0000, S C wrote:
>
> > Using MontaVista Linux 3.1 on a Toshiba RBTx4938 board. Using YAMON, 
>when I
> > download the kernel via the debug ethernet port it runs fine. If I 
>download
> > the kernel via the Tx4938 inbuilt ethernet controller, it crashes!
>
>If you're using a Montavista kernel you should report to Montavista.  We
>don't have the source so any comment here is speculation.
>
> > The crash is occuring inside the function r4k_flush_icache_range().
> >
> > I tried 'flush -i' and 'flush -d' on YAMON after the download but before
> > the 'go', but that didn't help. I also tried completely disabling caches
> > and loading/running uncached, but it gave the same error.
> >
> > Now, the final twist! Using an ICE, I set a breakpoint at the
> > r4k_flush_icache_range function. Then I loaded the kernel as usual, ran 
>it
> > with the ICE, stepped through a few instructions inside the
> > r4k_flush_icache_range function and then did a 'cont'. The kernel now
> > booted fine!
>
>As already pointed out by the other poster Niels Sterrenburg using a
>debugger unavoidably changes the state of the system to be debugged.
>
>For at least some of the TX49xx processors there is a problem under certain
>circumstances if a flush of an I-cache line flushes that cache instruction
>itself.  Make sure you're not getting hit by that one.
>
>   Ralf

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

---

From: "S C" <[email-masked]>
Date: Mon, 12 Jul 2004 23:10:29 +0000

Hi Kevin and Ralf,

Thanks for your inputs and suggestions! In the case of the Tx49 family, the 
primary I and D cache lines are both the same size (8 words), so the problem 
you mention below will not arise.

  I didn't think about the meaning of cpu_has_ic_fills_f_dc before writing 
my previous mail, and I see now that my intuition (and your explanation 
helps) was correct.

  For the moment, the problem is fixed. But I'm going to try and get to the 
bottom of this when I have the time.

  Thanks,
-Steve.

>From: "Kevin D. Kissell" <[email-masked]>
>To: "Kevin D. Kissell" <[email-masked]>, "S C" 
><[email-masked]>,        "Ralf Baechle" <[email-masked]>
>CC: <[email-masked]>
>Date: Tue, 13 Jul 2004 00:25:37 +0200
>
> > 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
> > set.
>
>Hmm.  On closer examination, there *is* a bug in the current 
>r4k_flush_icache_range(),
>in that it computes its cache flush loop for the I-cache based on the 
>D-cache line size.
>Those line sizes are *usually* the same.  By any chance are they different 
>for the
>TX49 family?  If the icache line is longer than the dcache line, there 
>should be no
>functional problem, just some wasted cycles.  But if the dcache line were, 
>say,
>twice the length of the Icache line, only half of the icache lines would be 
>invalidated...
>
>             Regards,
>
>             Kevin K.
>