2008-12-01 12:46:51     L1 data cache issue

Document created by Aaronwu Employee on Aug 8, 2013
Version 1Show Document
  • View in full screen mode

2008-12-01 12:46:51     L1 data cache issue

Vasanth Nayak (INDIA)

Message: 66099   

 

HI,

 

        Iam having a issue where enabling D-cache gives a kernel panic. I am using 2008R1.5 kernel and building a multithreaded application. I have enabled I-cache and using data SRAM as well (using __attribute((l1_data)). I also have kernel module( a device driver) linked into the kernel. Iam using "write back" policy and using D-cache on both L1 banks(L1_dataA and L1_dataB).

 

The application runs fine when Data cache is disabled.

 

Is there any relation to this problem with some options regarding placement of CPLB's in "kernel optimization " (in make menuconfig)

 

Any help will be deeply appreciated.

 

 

 

 

QuoteReplyEditDelete

 

 

2008-12-01 13:31:04     Re: L1 data cache issue

Robin Getz (UNITED STATES)

Message: 66100   

 

Vasanth:

 

There have been no reports about data cache not working properly. (unless it is on really old silicon).

 

Need more info before we can help out. What does the kernel OOPs look like?

 

-Robin

QuoteReplyEditDelete

 

 

2008-12-01 13:40:56     Re: L1 data cache issue

Mike Frysinger (UNITED STATES)

Message: 66102   

 

as well as the OOPS, you need to actually describe the hardware in use.  and post the full boot output.

QuoteReplyEditDelete

 

 

2008-12-02 05:49:26     Re: L1 data cache issue

Vasanth Nayak (INDIA)

Message: 66150   

 

Hi,

 

      Iam using BF527 ezkit.Please find attached the kernel-oops dump and the startup print dump. One more thing to be noticed is that i get 0x27 in EXCAUSE

 

0x27

   

 

Data access multiple CPLB hits

   

 

More than one CPLB entry matches data fetch address

 

I guess this may be the cause of kernel panic.

 

And the kernel oops is not obtained if D-cache is disabled.

 

 

 

Vasanth

 

kernel-panic-dump.txt

startup-print.txt

QuoteReplyEditDelete

 

 

2008-12-02 06:02:45     Re: L1 data cache issue

Mike Frysinger (UNITED STATES)

Message: 66152   

 

if you read the message instead of trying to decode seqstat, you'd see that the code is using a NULL pointer

 

in this case, i'm guessing your code does not flush things properly and then attempts to use invalid data which results in a crash

QuoteReplyEditDelete

 

 

2008-12-02 06:42:59     Re: L1 data cache issue

Vasanth Nayak (INDIA)

Message: 66158   

 

Hi Mike,

 

                  Thanks for the reply.

 

what are the typical scenarios when the data cache needs to be flushed ?

 

(In my particular application, iam using a kernel module and the problem appears to stem from that module).

QuoteReplyEditDelete

 

 

2008-12-02 06:57:28     Re: L1 data cache issue

Mike Frysinger (UNITED STATES)

Message: 66160   

 

if you're using DMA, then read this:

http://docs.blackfin.uclinux.org/doku.php?id=dma_systems

QuoteReplyEditDelete

 

 

2008-12-02 08:03:27     Re: L1 data cache issue

Vasanth Nayak (INDIA)

Message: 66168   

 

Mike,

 

            other than when using DMA, Are there any other reasons where data cache needs to be invalidated / flushed ?

QuoteReplyEditDelete

 

 

2008-12-02 08:13:14     Re: L1 data cache issue

Michael Hennerich (GERMANY)

Message: 66169   

 

I don't think this is anyhow related to D-CACHE or DMA.

As soon as you turn of D-CACHE our NULL Pointer catch doesn’t work anymore.

 

Try following - Let D-CACHE On and turn OFF 'Catch NULL pointer reads/writes' in kernel hacking.

I think your application simply does a Null Pointer access, to address 0xC

 

-Michael

 

 

QuoteReplyEditDelete

 

 

2008-12-02 09:52:36     Re: L1 data cache issue

Vasanth Nayak (INDIA)

Message: 66170   

 

Hi Michael,

 

                     Thanks for the suggestion. I tried that and now its WORKING(even with D-cache enabled). from the assembly, it seemed it was reading from 0x0c.But iam not sure i have understood why it was working with D-cache disabled and not with D-cache enabled (without 'Catch NULL pointer reads/writes' kernel hack).

QuoteReplyEditDelete

 

 

2008-12-02 10:53:37     Re: L1 data cache issue

Michael Hennerich (GERMANY)

Message: 66172   

 

The 'Catch NULL pointer reads/writes' option places an additional CPLB entry at Address 0 - 0x1000.

If now an application tries to access this memory space it generates a Multiple CPLB hit exception.

Which prints out this dump.

If you disable D-Cache you also disable the entire Memory Protection and Cacheability Unit.

 

See more here:

http://docs.blackfin.uclinux.org/doku.php?id=debuging_applications

 

Try to find out who writes to 0xC

-Michael

QuoteReplyEditDelete

 

 

2008-12-02 10:58:22     Re: L1 data cache issue

Michael Hennerich (GERMANY)

Message: 66173   

 

Just saw you posted some dumps:

 

RETX: <0x00380034> { :TimerModule:_timer_poll + 0x10 }

 

 

This is where the access happens!

 

-Michael

 

QuoteReplyEditDelete

 

 

2008-12-02 15:25:03     Re: L1 data cache issue

Mike Frysinger (UNITED STATES)

Message: 66180   

 

ah true, i forgot about that ... another reason for Robin to split the logic between caching and protection

Outcomes