All of lore.kernel.org
 help / color / mirror / Atom feed
* Strange, strange occurence
@ 2004-07-09 18:50 S C
  2004-07-10  7:33 ` Niels Sterrenburg
  2004-07-10 10:04 ` Ralf Baechle
  0 siblings, 2 replies; 44+ messages in thread
From: S C @ 2004-07-09 18:50 UTC (permalink / raw)
  To: linux-mips

Well I'm hoping it isn't so strange to some of you folks and you'll be able 
to tell what's going on :)

Here's my problem:

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!

Memory checksumming and a quick manual memory dump inspection reveals that 
the kernel download went perfectly ok, and the image is completely and 
correctly downloaded to RAM.

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!

If I don't set the breakpoint inside that function though, and just try to 
run with the ICE the same
error (Inst fetch/Load error) occurs.

I'm at a loss trying to figure out what's going on. I suspect it has 
something to do with caches perhaps (duh!), but have no clue what!  Anybody 
out there face a similar kind of a situation before?

Thanks in advance for any help offered.

Regards,
-Steve

_________________________________________________________________
MSN 9 Dial-up Internet Access helps fight spam and pop-ups – now 2 months 
FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: Strange, strange occurence
@ 2004-07-12 20:49 S C
  0 siblings, 0 replies; 44+ messages in thread
From: S C @ 2004-07-12 20:49 UTC (permalink / raw)
  To: ralf; +Cc: linux-mips

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 <ralf@linux-mips.org>
>To: S C <theansweriz42@hotmail.com>
>CC: linux-mips@linux-mips.org
>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/

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: Strange, strange occurence
@ 2004-07-12 21:23 S C
  2004-07-12 21:48   ` Kevin D. Kissell
  2004-07-12 23:00 ` Ralf Baechle
  0 siblings, 2 replies; 44+ messages in thread
From: S C @ 2004-07-12 21:23 UTC (permalink / raw)
  To: ralf; +Cc: linux-mips

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.

Regards,
-Steve.





>From: Ralf Baechle <ralf@linux-mips.org>
>To: S C <theansweriz42@hotmail.com>
>CC: linux-mips@linux-mips.org
>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

_________________________________________________________________
Check out the latest news, polls and tools in the MSN 2004 Election Guide! 
http://special.msn.com/msn/election2004.armx

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: Strange, strange occurence
@ 2004-07-12 23:10 S C
  0 siblings, 0 replies; 44+ messages in thread
From: S C @ 2004-07-12 23:10 UTC (permalink / raw)
  To: KevinK, ralf; +Cc: linux-mips

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" <KevinK@mips.com>
>To: "Kevin D. Kissell" <KevinK@mips.com>, "S C" 
><theansweriz42@hotmail.com>,        "Ralf Baechle" <ralf@linux-mips.org>
>CC: <linux-mips@linux-mips.org>
>Subject: Re: Strange, strange occurence
>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.
>

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

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: Strange, strange occurence
@ 2004-07-30 21:06 G H
  2004-07-31  5:09 ` Ralf Baechle
  0 siblings, 1 reply; 44+ messages in thread
From: G H @ 2004-07-30 21:06 UTC (permalink / raw)
  To: linux-mips

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Is the suggested patch below going to be added to CVS or is considered too experimental to add ?
 
>No and yes - but here is a simpler solution.  Below patch solves the
>problem and adds just 32 bytes of code but removes the special case for
>TX49/H2 entirely.

>  Ralf

> arch/mips/mm/c-r4k.c        |   59 
>-------------------------------------------- include/asm-mips/r4kcache.h |   18 
>++++++++-----
> include/asm-mips/war.h      |   14 ----------
> 3 files changed, 13 insertions(+), 78 deletions(-)
>
>
>Index: arch/mips/mm/c-r4k.c
>===================================================================
>RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
>retrieving revision 1.88
>diff -u -r1.88 c-r4k.c
>--- arch/mips/mm/c-r4k.c        16 Jul 2004 12:06:13 -0000      1.88
>+++ arch/mips/mm/c-r4k.c        16 Jul 2004 12:17:05 -0000
>@@ -96,16 +96,6 @@
>                r4k_blast_dcache = blast_dcache32;
> }


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread
end of thread, other threads:[~2004-07-31  5:09 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-09 18:50 Strange, strange occurence S C
2004-07-10  7:33 ` Niels Sterrenburg
2004-07-10 10:04 ` Ralf Baechle
2004-07-12 15:16   ` Kevin D. Kissell
2004-07-12 15:16     ` Kevin D. Kissell
2004-07-13  0:33     ` Ralf Baechle
2004-07-13  7:49       ` Help with MOP network boot install on DECstation 5000/240 Collin Baillie
2004-07-13  8:03         ` Jan-Benedict Glaw
2004-07-14  6:57           ` Collin Baillie
2004-07-14  9:54             ` Maciej W. Rozycki
2004-07-14 12:44               ` Jan-Benedict Glaw
2004-07-14 12:51                 ` Maciej W. Rozycki
2004-07-14 13:30                   ` Jan-Benedict Glaw
2004-07-15 11:33                     ` Maciej W. Rozycki
2004-07-14 12:43             ` Jan-Benedict Glaw
2004-07-16 14:41               ` Collin Baillie
2004-07-16 15:04                 ` Jan-Benedict Glaw
2004-07-16 15:13                   ` Maciej W. Rozycki
2004-07-16 15:08                 ` Maciej W. Rozycki
2004-07-16 16:31                   ` Thiemo Seufer
2004-07-16 16:51                     ` Maciej W. Rozycki
2004-07-16 18:56                       ` Thiemo Seufer
2004-07-13 15:31       ` Strange, strange occurence Kevin D. Kissell
2004-07-13 15:31         ` Kevin D. Kissell
2004-07-14 12:02         ` Maciej W. Rozycki
2004-07-14 16:35       ` Dominic Sweetman
2004-07-14 17:45         ` Michael Uhler
2004-07-14 17:45           ` Michael Uhler
2004-07-15  1:34         ` Atsushi Nemoto
2004-07-15  1:53         ` Ralf Baechle
2004-07-16 12:24         ` Ralf Baechle
2004-07-16 16:05           ` Atsushi Nemoto
  -- strict thread matches above, loose matches on Subject: below --
2004-07-12 20:49 S C
2004-07-12 21:23 S C
2004-07-12 21:48 ` Kevin D. Kissell
2004-07-12 21:48   ` Kevin D. Kissell
2004-07-12 22:25   ` Kevin D. Kissell
2004-07-12 22:25     ` Kevin D. Kissell
2004-07-12 23:13     ` Ralf Baechle
2004-07-12 23:11   ` Ralf Baechle
2004-07-12 23:00 ` Ralf Baechle
2004-07-12 23:10 S C
2004-07-30 21:06 G H
2004-07-31  5:09 ` Ralf Baechle

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.