Dear Mr. Kissell and the others,
I apologize for my rude question if you felt like. I was first in this
mailing list and I didn't think I had to describe the background of my
problem such in depth. I have an application stored in an onboard block
device and it sometimes makes bus error or segmentation fault during
When the application is stored in and executed from an nfs device or an
ramfs or any other device, it works without any problem. So I think the
problem comes from the device driver or something below.
In some experiments, the cache invalidation in a point reduces the frequency
of abnormal terminations. (I don't know it's a walk-around or just reduction
yet) When the application was copied from the device onto the other (ram or
network) device, it works well. So I guess the problem is related to the
cache and not from just d-cache incoherency. I targeted the consistency
between d- and i-cache as first. If you have any idea, please let me know.
For the device driver for the block device is very large and not my work,
I'm still in the dark. ^^;
Thank you for your hints about the interrupt disabling and the variable
cachability. They could be very helpful for me. For the tag, I meant the
physical address field of the valid tag. Thank you again.
From: Kevin D. Kissell [mailto:email@example.com]
Sent: Monday, April 24, 2006 4:41 PM
To: Kim, Jong-Sung; firstname.lastname@example.org
Subject: Re: Reading an entire cacheline
Yes, your question was too brief the first time around - I couldn't
tell what you were really asking. I'm still not 100% sure of what
you're doing, though. I don't want to sound insulting, but you're
disabling interrupts during this operation, right? And if you're
copying the values into variables in memory, you're doing nothing
but non-cached references, right? When you see the tags changing
on you, which bits are changing, and what are they defined to mean?
----- Original Message -----
From: "Kim, Jong-Sung" <email@example.com>
Sent: Monday, April 24, 2006 9:23 AM
Subject: RE: Reading an entire cacheline
> Hi all,
> Was my question too brief? I'm using MIPS5Kf core included in a Broadcom
> implemented processor and it has a 32kB d-cache and a same sized i-cache.
> Cache configuration is 2-way, 32-byte cacheline for both d- and i-cache
> without L2 cache. Of course, MIPS-port Linux as the kernel for it. And, a
> onboard block device has problem in its operation. I don't think it's a
> kernel problem. So I wanna inspect the contents of cache RAMs at the
> driver's context. I've added some lines of codes look like follow:
> __asm__ __volatile__(
> ".set noreorder\n\t"
> ".set mips3\n\t"
> "cache 5, 0x00(%3)\n\t" // load d-cache tag
> ".set mips0\n\t" // by index
> ".set mips32\n\t"
> "mfc0 %0, $28, 0\n\t"
> "mfc0 %1, $28, 1\n\t"
> "mfc0 %2, $29, 1\n\t"
> .set mips0\n\t"
> .set reorder"
> : "=r" (tag), "=r" (data_lo), "=r" (data_hi)
> : "r" (0x80000000 | (way << 14) | (index << 5) | (word <<
> This is executed for every index, every way, and every word. The thing
> my head is the tags from a single cacheline differs. (very often for
> d-cache) So I modified the code to reread the cacheline from the first
> when the tag was modified before reading all four words. Then the code
> return. I couldn't find any related information from manual.
> Please give me a hint for reading whole cacheline safely.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Kim, Jong-Sung
> Sent: Tuesday, April 18, 2006 9:37 AM
> To: firstname.lastname@example.org
> Subject: Reading an entire cacheline
> Is there any way to read an entire cacheline from the MIPS5Kf? Four
> sequential cache instructions do similarly, but sometimes the tags from a
> same cacheline differ. How can I read a consistent cacheline safely?