From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>, "Jun Sun" <jsun@mvista.com>
Cc: "Pete Popov" <ppopov@mvista.com>,
"Quinn Jensen" <jensenq@lineo.com>, <linux-mips@oss.sgi.com>
Subject: Re: CONFIG_MIPS_UNCACHED
Date: Fri, 26 Jan 2001 11:02:24 +0100 [thread overview]
Message-ID: <00e201c0877f$1acfdb80$0deca8c0@Ulysses> (raw)
In-Reply-To: 20010124163101.F863@bacchus.dhis.org
>
> > It is really surprising to know this. It sounds like a CPU bug to me.
Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
>
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0. Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory. The window is very small but yet exists if
> things are just right.
That's one possible failure mode. The other is that there
are dirty lines (those that were brought into the cache and
modified by stores, but never written back to memory) that
are rendered invisible by forcing KSEG0 to go uncached.
This will cause failure of any code that is expecting to see
the results of those stores if said code executes before
some other event causes the write-back - and if the
machine is running with cacheing completely disabled,
as it would be in the case under discussion, such an
event may never occur!
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralf Baechle <ralf@oss.sgi.com>, Jun Sun <jsun@mvista.com>
Cc: Pete Popov <ppopov@mvista.com>, Quinn Jensen <jensenq@lineo.com>,
linux-mips@oss.sgi.com
Subject: Re: CONFIG_MIPS_UNCACHED
Date: Fri, 26 Jan 2001 11:02:24 +0100 [thread overview]
Message-ID: <00e201c0877f$1acfdb80$0deca8c0@Ulysses> (raw)
Message-ID: <20010126100224.ynZUFDb6ME2teh9iuYpTj0Bi-6K7P8L8p5-4onBgyrA@z> (raw)
In-Reply-To: 20010124163101.F863@bacchus.dhis.org
>
> > It is really surprising to know this. It sounds like a CPU bug to me.
Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
>
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0. Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory. The window is very small but yet exists if
> things are just right.
That's one possible failure mode. The other is that there
are dirty lines (those that were brought into the cache and
modified by stores, but never written back to memory) that
are rendered invisible by forcing KSEG0 to go uncached.
This will cause failure of any code that is expecting to see
the results of those stores if said code executes before
some other event causes the write-back - and if the
machine is running with cacheing completely disabled,
as it would be in the case under discussion, such an
event may never occur!
Regards,
Kevin K.
next prev parent reply other threads:[~2001-01-26 9:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-23 23:26 CONFIG_MIPS_UNCACHED Quinn Jensen
2001-01-23 23:53 ` CONFIG_MIPS_UNCACHED Pete Popov
2001-01-24 20:10 ` CONFIG_MIPS_UNCACHED Jun Sun
2001-01-25 0:31 ` CONFIG_MIPS_UNCACHED Ralf Baechle
2001-01-25 1:09 ` CONFIG_MIPS_UNCACHED Pete Popov
2001-01-25 1:37 ` CONFIG_MIPS_UNCACHED Jun Sun
2001-01-26 10:02 ` Kevin D. Kissell [this message]
2001-01-26 10:02 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
-- strict thread matches above, loose matches on Subject: below --
2001-06-23 16:05 CONFIG_MIPS_UNCACHED Jun Sun
2001-06-23 17:17 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-23 17:17 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-23 17:49 ` CONFIG_MIPS_UNCACHED Jun Sun
2001-06-23 20:15 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-23 20:15 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-25 4:42 ` CONFIG_MIPS_UNCACHED Jun Sun
2001-06-25 6:51 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-25 6:51 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-25 16:38 ` CONFIG_MIPS_UNCACHED Jun Sun
2001-06-25 17:35 ` CONFIG_MIPS_UNCACHED Justin Carlson
2001-06-26 8:50 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-26 8:50 ` CONFIG_MIPS_UNCACHED Kevin D. Kissell
2001-06-26 13:11 ` CONFIG_MIPS_UNCACHED Maciej W. Rozycki
2001-06-25 13:22 ` CONFIG_MIPS_UNCACHED Maciej W. Rozycki
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='00e201c0877f$1acfdb80$0deca8c0@Ulysses' \
--to=kevink@mips.com \
--cc=jensenq@lineo.com \
--cc=jsun@mvista.com \
--cc=linux-mips@oss.sgi.com \
--cc=ppopov@mvista.com \
--cc=ralf@oss.sgi.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