linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: joakim.tjernlund@transmode.se
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Problems in 2.6 memory management on 8xx
Date: Thu, 24 May 2007 18:45:36 +0200	[thread overview]
Message-ID: <m2hcq2b26n.fsf@sowhat.denx.de> (raw)
In-Reply-To: <1180023834.1468.64.camel@gentoo-jocke.transmode.se> (Joakim Tjernlund's message of "Thu\, 24 May 2007 18\:23\:54 +0200")

Hi Joakim,

> On Thu, 2007-05-24 at 17:23 +0200, Joakim Tjernlund wrote:
>> On Thu, 2007-05-24 at 15:07 +0200, Detlev Zundel wrote:
>> > Hi,
>> > 
>> > working on a 2.6.16 kernel on a 870 CPU, I ran into this strange
>> > behaviour exemplified by the simple attached demo program.  An icbi
>> > from userspace on an address that is mapped only lazily gets into an -
>> > though interruptible - loop. Locking the icbi target in question with
>> > mlock circumvents this problem.
>> 
>> 8xx is buggy w.r.t cache instructions. They do not update the
>> DAR register in the TLB miss/TLB error handlers.
>> The TLB miss handler does not use the DAR reg but the TLB error
>> handler do. Thats why it works when you mlock the memory.
>> 
>> This bug isn't documented but Freescale has confirmed it.
>> You can search the archives some years back for more info.
>> 
>>  Jocke
>
> BTW, it is possible to workaround this problem in the kernel by
> tagging DAR with an impossible value and compare DAR against it
> in the DTLB Error handler. If a match, then do a instruction decode
> to get the regs involved and calculate the faulting address.
>
> I did this several years ago for 2.4 in assembler and posted
> it, but it was rejected.
> One should bail out to handle_page_fault and do the
> calculations there instead(less likely to break that way)
>
> Found one version of the patch here:
> http://patchwork.ozlabs.org/linuxppc/patch?id=1307

Thanks for shedding some light on this problem.  I already found the
patch you refer to and also wondered why it was never accepted.  Was
there a technical reason or did it simply slip everybodys attention?

Cheers
  Detlev

-- 
Men are born ignorant, not stupid; they are made stupid by education.
					  --Bertrand Russell
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

  reply	other threads:[~2007-05-24 16:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-24 13:07 Problems in 2.6 memory management on 8xx Detlev Zundel
2007-05-24 15:23 ` Joakim Tjernlund
2007-05-24 16:23   ` Joakim Tjernlund
2007-05-24 16:45     ` Detlev Zundel [this message]
2007-05-24 17:10       ` 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=m2hcq2b26n.fsf@sowhat.denx.de \
    --to=dzu@denx.de \
    --cc=joakim.tjernlund@transmode.se \
    --cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).