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 16:09:29 +0100 [thread overview]
Message-ID: <20030911160929.A19449@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030911123535.GB28180@mail.jlokier.co.uk>; from jamie@shareable.org on Thu, Sep 11, 2003 at 01:35:35PM +0100
On Thu, Sep 11, 2003 at 01:35:35PM +0100, Jamie Lokier wrote:
> Russell King wrote:
> > > Does your fix, which makes pages uncacheable andq disables write
> > > combining (correct?) only fix your test results which intermittently
> > > reported write buffer problems, or does it fix _all_ the ARM test
> > > results I received, including those which don't report write buffer
> > > problems?
> >
> > It's relatively simple, and I'm not sure why its causing such
> > misunderstanding. Let me try one more time:
> >
> > 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.
>
> That I understand fully.
I don't think you do.
> My question arises because I have 3 SA-110 results which report "cache
> not coherent". They do not report "store buffer not coherent". All 3
> are Rebel Netwinders, of different bogomips ratings.
>
> The point is: those results _don't_ indicate write buffer problems.
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.
> It means that your VIVT explanation and workaround does not explain
> those results, so I cannot have confidence that your workaround fixes
> those particular ARM devices.
Well, as far as I'm concerned, I completely believe that I have explained
it entirely, and I still don't know why you're trying to make this more
difficult than it factually is.
> Now, if you can assure me that those results are _definitely_ due to
> using very old kernels which don't even mark pages uncacheable, and
> with newer kernels those Netwinders would exhibit coherent virtual
> aliases, that's great.
Well, once you collect the kernel information and forward it to me, I
can have a look.
--
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 15:09 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 [this message]
2003-09-11 16:25 ` Jamie Lokier
2003-09-11 16:52 ` Russell King
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=20030911160929.A19449@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.