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
next prev parent 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).