From: Till Straumann <strauman@SLAC.Stanford.EDU>
To: DigitalDNA Help <DigitalDNA.Help@motorola.com>
Cc: linuxppc-embedded@lists.linuxppc.org, linux-kernel@vger.kernel.org
Subject: Re: Motorola DigitalDNA Help, Service Request # 1-1H8Q6 Follow - MPC8xx not setting DAR when DCBZ faults
Date: Tue, 05 Dec 2000 11:41:18 -0800 [thread overview]
Message-ID: <3A2D44DE.3EA01C6B@slac.stanford.edu> (raw)
In-Reply-To: <39F56211.A2470D18@tcfc.tornado.nsk.ru>
Motorola DigitalDNA Help wrote:
> Dear Till Strauamnn,
>
> in reply to your Service Request SR 1-1H8Q6 (see details below):
>
> You are right. We've tested your code. It behaves the same way with
> other 860 parts.
> Let us know if this feature creates a problem for you and we'll try to
> find a solution (if it's possible).
Sorry for coming back to this late. I am working on different projects and
some high priority tasks eat up my time...
First of all, it seems that we disagree a little bit on the impact this problem
has. I discovered it running RT-Linux.
Not setting DAR when an address is not found in the TLB as it happens
on the MPC860 with the dcbz (& similar) instructions means that
you must not use these instructions on any system that does not keep all
of its address mappings in the TLBs permanently, because there is no way
for the TLB replacement algorithm to figure out the fault address.
Most of the PowerPC cache manipulation instructions are executable in
user mode, i.e. they may be present in any program / library that is ported
to MPC860. On linux, executing such a program may occasionally cause it to
mysteriously "segfault". Portions of the LINUX kernel are also affected.
If need more pages of memory than there are TLBs in the 860, I have to
scan all the software I intend to use on this machine for the cache instructions
and eliminate them (with some impact on performance, of course).
Me (and I'm sure there are many others affected by this problem although
they might not know it - after all, it was pretty hard to track down, for me too)
would certainly apreciate you to try to figure out a solution.
Regards, Till Straumann.
PS: cc questions/replies to me, as I am not on the mailing lists.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
parent reply other threads:[~2000-12-05 20:12 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <39F56211.A2470D18@tcfc.tornado.nsk.ru>]
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=3A2D44DE.3EA01C6B@slac.stanford.edu \
--to=strauman@slac.stanford.edu \
--cc=DigitalDNA.Help@motorola.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-embedded@lists.linuxppc.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
all inboxes | Powered by JetHome®