From: Russell King <rmk@arm.linux.org.uk>
To: Jamie Lokier <jamie@shareable.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Virtual alias cache coherency results (was: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this)
Date: Thu, 11 Sep 2003 17:52:24 +0100 [thread overview]
Message-ID: <20030911175224.A20308@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030911162510.GA29532@mail.jlokier.co.uk>; from jamie@shareable.org on Thu, Sep 11, 2003 at 05:25:10PM +0100
On Thu, Sep 11, 2003 at 05:25:10PM +0100, Jamie Lokier wrote:
> Russell King wrote:
> > Maybe those StrongARM chips don't exhibit the write buffer bug? Remember,
> > I said _SOME_ StrongARM-110 chips exhibit the problem. I did not say
> > _ALL_ StrongARM-110 chips exhibit the problem.
>
> I never assumed they all have the bug. Credit me with at least
> reading what you wrote before! :)
>
> The results indicate some StrongARM-110 systems which _don't_ exhibit
> the write buffer bug _do_ exhibit some _other_ cause of non-coherence.
Sigh. Let me re-state one more time. If you don't get it this time
around, I can't help you to understand, and I ask that you drop all
information concerning ARM from your document in case you mislead other
parties who may think you're stating definitive information.
It would appear that you've completely forgotten about my previous
statements:
| ARM caches are VIVT. VIVT caches have inherent aliasing issues. The
| kernel works around these issues by marking memory uncacheable where
| appropriate, and will continue to do so for VIVT cached ARM CPUs.
On 1st September, I wrote:
| This looks like an old kernel on your NetWinder. Later 2.4 kernels
| should get this right (by marking the pages uncacheable in user space.)
So this says that there _are_ old kernels which didn't do any fixup
_and_ I pointed out that you were receiving reports from such kernels.
> ...until we learn what kernel versions the Netwinder folks are
> running, or they kindly run the test on a new kernel.
Absolutely - so what _you_ need to do now is to go off to each person
who responded (only _you_ have those details and therefore only _you_
can do this) and _ask_ them the question.
Now, lets rewind back to the original mail. You said:
|> CPUs with incoherent write buffers: PA-RISC 2.0, 68040 and ARMs.
I still claim this is an inaccurate summary, and is misleading - this
says "All ARMs have incoherent write buffers" which is many times removed
from reality.
Continuing:
|> SHMLBA not valid: ARM, m68k
|> On the ARM this is
|> believed to be due to a chip bug, and very recent kernels may contain
|> a workaround for it (disabling the write buffer for aliased pages).
I still claim this description is wrong. You are claiming that all ARMs
contain this bug and the kernel needs to work around it for all ARMs.
This is clearly not the case. In addition, the fact that a previously
undiscovered bug exists does not determine whether SHMLBA is valid or
not. The fact that SHMLBA _must_ be defined (it is not optional) _and_
there exists _no_ value for SHMLBA on the buggy _StrongARM_s does not
mean it is invalid as you are claiming.
--
Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
2.6 ARM Linux - http://www.arm.linux.org.uk/
2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2003-09-11 16:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-10 21:04 Virtual alias cache coherency results (was: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this) Jamie Lokier
2003-09-10 22:39 ` Russell King
2003-09-10 23:37 ` Jamie Lokier
2003-09-11 0:07 ` Russell King
2003-09-11 12:35 ` Jamie Lokier
2003-09-11 15:09 ` Russell King
2003-09-11 16:25 ` Jamie Lokier
2003-09-11 16:52 ` Russell King [this message]
2003-09-11 18:55 ` Jamie Lokier
2003-09-12 0:45 ` Jamie Lokier
2003-09-12 7:48 ` Russell King
2003-09-11 18:51 ` Guennadi Liakhovetski
2003-09-11 10:17 ` Richard Curnow
2003-09-11 16:34 ` Jamie Lokier
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=20030911175224.A20308@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.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