From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5728 invoked by alias); 21 Sep 2012 17:01:17 -0000 Received: (qmail 5703 invoked by uid 22791); 21 Sep 2012 17:01:14 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_CB,TW_DN,TW_LR,TW_SR X-Spam-Check-By: sourceware.org Received: from quartz.orcorp.ca (HELO quartz.orcorp.ca) (184.70.90.242) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Sep 2012 17:01:01 +0000 Received: from [10.0.0.162] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TF6b6-00027e-Ni; Fri, 21 Sep 2012 11:01:00 -0600 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.76) (envelope-from ) id 1TF6b6-0002u2-I3; Fri, 21 Sep 2012 11:01:00 -0600 Date: Fri, 21 Sep 2012 17:01:00 -0000 From: Jason Gunthorpe To: crossgcc@sourceware.org, "Yann E. MORIN" Subject: [PATCH crosstool-ng] memsets to 0 over 256 bytes are broken on PowerPC 405 Message-ID: <20120921170100.GB30101@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.162 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00080.txt.bz2 The use_dcbz path in the hand coded assembly is assuming a 128 byte clear size for dcbz, but dcbz uses the cache line size and 405 cores only have a 32 byte cache line. So any clears to 0 that use the dcbz path fail to work. Some high end PPC's have a 128 byte cache line, but all 405's are 32 byte, see arch/powerpc/kernel/cputable.c, dcache_bsize assignments. This value flows from the kernel to glibc's __cache_line_size value which drives the dcbz step in the generic memset. Fix 405 memset.s to align and step the dcbz path to 32 byte cache lines. See http://sourceware.org/bugzilla/show_bug.cgi?id=14595 --- .../ports-2_13/100-powerpc-405-broken-memset.patch | 45 ++++++++++++++++++++ 1 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 patches/eglibc/ports-2_13/100-powerpc-405-broken-memset.patch This bug is present in all glibc's and eglibcs since at least 2.3.5 and results in PPC405 being completely broken. I've submitted it to glib-ports bugzilla and will forward to that mailing list as well.. diff --git a/patches/eglibc/ports-2_13/100-powerpc-405-broken-memset.patch b/patches/eglibc/ports-2_13/100-powerpc-405-broken-memset.patch new file mode 100644 index 0000000..d2c0a88 --- /dev/null +++ b/patches/eglibc/ports-2_13/100-powerpc-405-broken-memset.patch @@ -0,0 +1,45 @@ +memsets to 0 over 256 bytes are broken on PowerPC 405 + +The use_dcbz path in the hand coded assembly is assuming a 128 byte clear size +for dcbz, but dcbz uses the cache line size and 405 cores only have a 32 byte +cache line. So any clears to 0 that use the dcbz path fail to work. + +Some high end PPC's have a 128 byte cache line, but all 405's are 32 byte, +see arch/powerpc/kernel/cputable.c, dcache_bsize assignments. This value +flows from the kernel to glibc's __cache_line_size value which drives +the dcbz step in the generic memset. + +Fix 405 memset.s to align and step the dcbz path to 32 byte cache lines. + +See +http://sourceware.org/bugzilla/show_bug.cgi?id=14595 + +--- eglibc-2_13.orig/ports/sysdeps/powerpc/powerpc32/405/memset.S 2012-09-18 23:06:38.743817536 -0600 ++++ eglibc-2_13/ports/sysdeps/powerpc/powerpc32/405/memset.S 2012-09-18 23:09:48.677194920 -0600 +@@ -105,7 +105,7 @@ + add r3,r3,r7 + + L(skip_string_loop): +- clrlwi r8,r6,25 ++ clrlwi r8,r6,27 + srwi. r8,r8,4 + beq L(dcbz_pre_loop) + mtctr r8 +@@ -120,14 +120,14 @@ + bdnz L(word_loop) + + L(dcbz_pre_loop): +- srwi r6,r5,7 ++ srwi r6,r5,5 + mtctr r6 + addi r7,0,0 + + L(dcbz_loop): + dcbz r3,r7 +- addi r3,r3,0x80 +- subi r5,r5,0x80 ++ addi r3,r3,32 ++ subi r5,r5,32 + bdnz L(dcbz_loop) + srwi. r6,r5,4 + beq L(postword2_count_loop) -- 1.7.5.4 -- Jason Gunthorpe (780)4406067x832 Chief Technology Officer, Obsidian Research Corp Edmonton, Canada -- For unsubscribe information see http://sourceware.org/lists.html#faq