Problems in 2.6 memory management on 8xx

[Detlev Zundel]

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.

I tested this code on 2.6.21 on 4xx and 82xx only to prove that those
combinations, as expected, don't have this problem.  Vitaly Bordug was
kind enough to test the code on an 8xx hw supported by a recent kernel
and acknowledged it still being present.

As I don't have time to investigate this any further, I at least want
to document this problem with this post.  Maybe someone else can help
out here.

Thanks
  Detlev

-- 
-- Question authority!
-- Yeah, says who?
--
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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icbi.c
Type: text/x-csrc
Size: 437 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070524/f5f307fd/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icbi_trigger.S
Type: text/x-csrc
Size: 463 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070524/f5f307fd/attachment-0001.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070524/f5f307fd/attachment.txt>