All of lore.kernel.org
 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 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.