From: "Kevin D. Kissell" <kevink@mips.com>
To: "Jun Sun" <jsun@mvista.com>, "Carsten Langgaard" <carstenl@mips.com>
Cc: <linux-mips@linux-mips.org>, <jsun@mvista.com>
Subject: Re: possible Malta 4Kc cache problem ...
Date: Thu, 5 Dec 2002 10:27:10 +0100 [thread overview]
Message-ID: <009d01c29c40$85ccd9b0$10eca8c0@grendel> (raw)
In-Reply-To: 20021204141900.U4363@mvista.com
> 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.
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Jun Sun <jsun@mvista.com>, Carsten Langgaard <carstenl@mips.com>
Cc: linux-mips@linux-mips.org
Subject: Re: possible Malta 4Kc cache problem ...
Date: Thu, 5 Dec 2002 10:27:10 +0100 [thread overview]
Message-ID: <009d01c29c40$85ccd9b0$10eca8c0@grendel> (raw)
Message-ID: <20021205092710.CgnmKI_U2squbk4jIo9BFPgtp1EdWjSCh7MonrRB9LI@z> (raw)
In-Reply-To: 20021204141900.U4363@mvista.com
> 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.
Kevin K.
next prev parent reply other threads:[~2002-12-05 9:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 6:45 possible Malta 4Kc cache problem Jun Sun
2002-12-04 9:38 ` Kevin D. Kissell
2002-12-04 9:38 ` Kevin D. Kissell
2002-12-04 9:46 ` Kevin D. Kissell
2002-12-04 9:46 ` Kevin D. Kissell
2002-12-04 10:08 ` Carsten Langgaard
2002-12-04 11:21 ` Carsten Langgaard
2002-12-04 13:06 ` Kevin D. Kissell
2002-12-04 13:06 ` Kevin D. Kissell
2002-12-04 13:14 ` Carsten Langgaard
2002-12-04 13:28 ` Carsten Langgaard
2002-12-04 17:08 ` Kevin D. Kissell
2002-12-04 17:08 ` Kevin D. Kissell
2002-12-04 17:32 ` Daniel Jacobowitz
2002-12-04 20:28 ` Carsten Langgaard
2002-12-04 22:58 ` Jun Sun
2002-12-05 9:38 ` Carsten Langgaard
2002-12-06 16:42 ` Maciej W. Rozycki
2002-12-06 22:24 ` Hartvig Ekner
2002-12-06 22:24 ` Hartvig Ekner
2002-12-09 10:51 ` Dominic Sweetman
2002-12-09 10:51 ` Dominic Sweetman
2002-12-04 22:19 ` Jun Sun
2002-12-05 9:27 ` Kevin D. Kissell [this message]
2002-12-05 9:27 ` Kevin D. Kissell
2002-12-04 21:59 ` Jun Sun
2002-12-04 23:14 ` Kevin D. Kissell
2002-12-04 23:14 ` Kevin D. Kissell
2002-12-04 22:53 ` Jun Sun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009d01c29c40$85ccd9b0$10eca8c0@grendel' \
--to=kevink@mips.com \
--cc=carstenl@mips.com \
--cc=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox