linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Gary Thomas <gary@mlbassoc.com>,
	Brian Waite <waite@skycomputers.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Disable cache on 74xx
Date: Thu, 20 Feb 2003 10:23:27 -0500	[thread overview]
Message-ID: <3E54F2EF.2080601@embeddededge.com> (raw)
In-Reply-To: Pine.GSO.4.21.0302201507510.27212-100000@vervain.sonytel.be


Geert Uytterhoeven wrote:

> There may be a different behavior for `disabling the data cache globally' and
> `using e.g. dcbf on uncached memory' (with the data cache enabled globally).

I decided to take a diversion and read some processor manuals.  :-)

The behavior of the cache instructions on areas that are not cacheable
for any reason depends upon the cache instruction used.  Some have
no effect, some have unpredictable behavior, some cause alignment/access
traps.  It all depends upon how they would translate/access the cache
and the operation they would perform on a cache line.  We use all
instructions in Linux that would trigger any of the behavior. :-)

The bottom line appears to be you really don't want to execute cache
instructions on areas that are not cached.  This includes global disable
or any method of marking pages uncached.

For Brian, I'm also curious why you think running Linux with disabled caches
will assist in debugging memory controller problems?  If you are looking for
such fine control of the bus cycles for debugging it seems a simple
memory diagnostic used in conjuction with hardware debug tools is a
better approach.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-02-20 15:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-19 20:52 Disable cache on 74xx Brian Waite
2003-02-19 21:07 ` Benjamin Herrenschmidt
2003-02-19 22:48   ` Gary Thomas
2003-02-20 13:55     ` Brian Waite
2003-02-20 14:01       ` Gary Thomas
2003-02-20 14:09         ` Geert Uytterhoeven
2003-02-20 15:23           ` Dan Malek [this message]
2003-02-20 15:47             ` Brian Waite
2003-02-20 15:54               ` Gary Thomas
2003-02-20 15:55               ` Benjamin Herrenschmidt
2003-02-20 16:14               ` Dan Malek
2003-02-20 16:51                 ` Mark A. Greer
2003-02-20 14:09         ` Brian Waite

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=3E54F2EF.2080601@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=benh@kernel.crashing.org \
    --cc=gary@mlbassoc.com \
    --cc=geert@linux-m68k.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=waite@skycomputers.com \
    /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;
as well as URLs for NNTP newsgroup(s).