quoted

quoted

quoted

My configuration: Kernel 2.4.4, glibc 2.2.2, bash 2.05, FADS, MPC855T

...

quoted

binutils 2.11.2
gcc 2.95.3
glibc 2.2.2

Everything unpatched and downloaded from ftp.gnu.org.

yeah, sounds like the cacheline problem. It is still in glibc 2.2.2 and
2.2.3.

From what I read in the mailing list, I would also say it looks like this

problem.

I've recompiled my toolchain now with plain gnu software and the following
patches
from ftp.mvista.com and glibc-src package:
glibc22-27.patch               glibc22-getaddrinfo.dpatch
glibc22-disable-static.dpatch  glibc22-nss-upgrade.dpatch
glibc22-eo_EO.dpatch           glibcbug.dpatch

But the problem is still there.

I couldn't find 'the cacheline patch'. Is it the one mentioned here:
http://lists.linuxppc.org/listarcs/linuxppc-embedded/200003/msg00073.html

It contains for example this lines:

--- dl-machine.c.ORIG   Fri Mar  5 00:26:43 1999
+++ dl-machine.c        Sat Nov  6 14:33:47 1999

@@ -250,7 +250,11 @@
         PowerPC processors have line sizes of exactly 32 bytes.  */

       size_modified = lazy ? rel_offset_words :

PLT_INITIAL_ENTRY_WORDS;
+#ifdef PPC_CACHELINESIZE_32
       for (i = 0; i < size_modified; i+= 8)
+#else
+      for (i = 0; i < size_modified; i+= 4)
+#endif

But this increment is already at +4 in my nupatched glibc.






--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

--
GMX Tipp:

Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a