> On Wed, Dec 04, 2002 at 11:08:20AM +0100, Carsten Langgaard wrote:
> > I have just tried your test on a 4Kc and I see no problems.
> > However I'm running on our internal kernel sources, and as Kevin mention we
> > have
> > changed a fixed a few things in this area.
> > As Kevin also mention it sure look more like a I-cache invalidation problem,
> > rather than a D-cache flush problem, as the 4Kc has a write-through cache.
> > One think you could try, is our latest kernel release. You can find it here:
> > ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/
> Yes, the problem still exists with this kernel.
> Try to move the source tree to /root/, rename top dir to "try18",
> re-make the binary, and try again.
> This problem is tricky to reproduce. The location of the tree
> definitely matters. I am testing 32bit LE version. Have not
> tried BE.
> I think I have pinned down the problem. See my other follow-up posting.
Your results are certainly interesting and suspicious.
Before I take it up with the designers as a possible
hardware bug, I would really like to know if there
is more than one chip which exhibits this behavior.
In principle, it *could* be a manufacturing defect.
And while I acknowledge that your trace info
would seem to argue on the face of it that the
hardware didn't do what it should have done,
there is a remarkable similarity between what
you report and something that Carsten saw on
a couple of completely different CPUs a week
or two ago, which makes me wonder if there isn't
still some subtle software failure behind all this.
Thank you very, very, much for digging into
this as deeply as you have.