All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: Dan Malek <dan@embeddededge.com>
Cc: Paul Mackerras <paulus@samba.org>,
	linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: 8xx v2.6 TLB problems and suggested workaround
Date: Wed, 06 Apr 2005 09:00:57 +0300	[thread overview]
Message-ID: <42537B19.70206@intracom.gr> (raw)
In-Reply-To: <ba633c3356ff1ec71f53d4a0998132ff@embeddededge.com>

Dan Malek wrote:
> 
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> 
>> Problem is that the "dcbst" instruction will, _sometimes_ (the 
>> failure/success rate is about 1/4
>> with my test application) fault as a _write_ operation on the data.
> 
> 
> Oh, geeze .... It's all coming back to me now ....
> 
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions.  I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
> 
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs.  Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation match.
> 

OK, maybe we should make 8xx specifics cache flushing functions, that
use the SPR, and forget about this mess.

However is this problem also triggered by user space? If it is we should
try to maintain compatibility...

> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those.  During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.
> 
> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an #ifdef
> for the 8xx.  It seems if the dcbst causes a TLB miss during execution,
> it does the right thing.  We may want to make the dcbxxx instructions some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.
> 
> Thanks for the great work!
> 
> 
>     -- Dan
> 
> 
> 

Regards

Pantelis

  parent reply	other threads:[~2005-04-06  6:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-04 19:17 8xx v2.6 TLB problems and suggested workaround Marcelo Tosatti
2005-04-04 20:09 ` Marcelo Tosatti
2005-04-05  7:08   ` Pantelis Antoniou
2005-04-05  1:11 ` Kumar Gala
2005-04-05  3:14   ` PPC linux v2.6.11 network configuration hangs Pari Subramaniam
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
2005-04-05 11:41   ` Marcelo Tosatti
2005-04-05 20:26     ` Marcelo Tosatti
2005-04-06  6:00   ` Pantelis Antoniou [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-05 21:51 Joakim Tjernlund
2005-04-06 12:16 ` Marcelo Tosatti
2005-04-06 21:24   ` Joakim Tjernlund
2005-04-07 12:00     ` Marcelo Tosatti
2005-04-07 20:35       ` Joakim Tjernlund
2005-04-07 19:38         ` Marcelo Tosatti
2005-04-08  2:09           ` Dan Malek
2005-04-08 11:07             ` Marcelo Tosatti
2005-04-09  5:16               ` Dan Malek
2005-04-09 19:03                 ` Joakim Tjernlund
2005-04-09 22:37                   ` Marcelo Tosatti
2005-04-10 10:08                     ` Joakim Tjernlund
2005-04-22 17:14                     ` Marcelo Tosatti
2005-04-23 21:55                   ` Dan Malek
2005-04-23 22:07                     ` Joakim Tjernlund
2005-04-23 22:23                       ` Dan Malek
2005-04-08  8:01           ` Joakim Tjernlund
2005-04-08 13:39             ` Dan Malek
2005-04-08 14:29               ` Joakim Tjernlund

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=42537B19.70206@intracom.gr \
    --to=panto@intracom.gr \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=paulus@samba.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.