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