From patchwork Fri Sep 21 17:01:00 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 185841 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 431AC2C007C for ; Sat, 22 Sep 2012 03:01:25 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sourceware.org; s=default; x=1348851685; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-Help: Sender:Delivered-To; bh=T2Fleh+P8jgvxwZUuTNz4RYPaEE=; b=fkeX2R+F zbifiVdLdPRRlH4LRCqUgLQ+NuVtURpBXhCjhDzOvj+aONjaVW9wCB3nUHqRkDT7 cUYAU9gISpMr7y1vUA0rM6zYeeCxcRjlqMgcfKFN8KhLdxTafwzRq/7wcAnAkgNf yvEVn0v3c6bu3zIMhGKboYD78P9VFX8bhLg= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sourceware.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-Broken-Reverse-DNS:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=OR4qSDzXk6rkaM8gBpVUijHSgHS3Dbq/gEgnOvw5je+HSwxhV7yGhPu0i1cgyA AK+yExyIqrWFquHIdCILz6J6pIPJEj6XMZsTxjCqpfdUKYiPxNckgoHLv5t5NV8V 4iMRQeXOAXYmhG+q72zvSX+lStyxWGTCx9u1GynjwQrRE=; 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 11:01:00 -0600 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-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-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Delivered-To: mailing list crossgcc@sourceware.org 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)