From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 972B37F5F for ; Thu, 28 Feb 2013 20:25:47 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 225E1AC003 for ; Thu, 28 Feb 2013 18:25:43 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id W1ikGr7718F7wSkP for ; Thu, 28 Feb 2013 18:25:42 -0800 (PST) Date: Fri, 1 Mar 2013 13:25:39 +1100 From: Dave Chinner Subject: Re: Read corruption on ARM Message-ID: <20130301022539.GR5551@dastard> References: <512E7639.20205@sandeen.net> <512E89C2.9000302@sandeen.net> <512E903A.2020405@sandeen.net> <512EDF37.4050802@sandeen.net> <512EE20A.7010103@sandeen.net> <512EEAB8.4070306@sandeen.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Jason Detring Cc: Eric Sandeen , xfs-oss On Thu, Feb 28, 2013 at 03:38:51PM -0600, Jason Detring wrote: > On 2/27/13, Eric Sandeen wrote: > > On 2/27/13 10:50 PM, Eric Sandeen wrote: > >> On 2/27/13 10:38 PM, Eric Sandeen wrote: > >> > >> ... > >> > >>> re-cc'ing xfs list > >>> > >>> So I used pahole to look at all structs, objdump -d to disassemble, > >>> and md5sum'd the results to see what's different. > >>> > >>> pi@raspberrypi ~ $ md5sum cross/*.dis cross/*.pahole native/*.dis > >>> native/*.pahole > >>> > >>> > >>> > >>> c0abd80c3bf049db5e1909fd851261cc cross/xfs-O1-g.ko.pahole > >>> c0abd80c3bf049db5e1909fd851261cc cross/xfs-O2-g.ko.pahole > >>> c0abd80c3bf049db5e1909fd851261cc cross/xfs-Os-g.ko.pahole > >>> c0abd80c3bf049db5e1909fd851261cc native/xfs-O1-g.ko.pahole > >>> c0abd80c3bf049db5e1909fd851261cc native/xfs-O2-g.ko.pahole > >>> c0abd80c3bf049db5e1909fd851261cc native/xfs-Os-g.ko.pahole > >>> > >>> so all structures look identical, good - but: > >>> > >>> while disassembly of these two modules match: > >>> > >>> d76f6ebf4d8a1b9f786facefbcf16f69 cross/xfs-O1-g.ko.dis > >>> d76f6ebf4d8a1b9f786facefbcf16f69 native/xfs-O1-g.ko.dis > >>> > >>> do you see the problem w/ the cross-compiled xfs-O1-g.ko as well? > > No, I didn't. The problem has only shown itself on the -O2 builds, > both native and cross-compiled. Lower optimization levels don't show > any of the symptoms. > > Perhaps a better comparison would be-O2 builds among working and > non-working compilers? You'd asked for these before, but I just > finished them today. The modules, build logs, and fs/xfs/ build trees > are up at > > A quick rundown: > -cross-gcc4.4: OK > -cross-gcc4.5: OK > -cross-gcc4.6: BAD > -cross-gcc4.7: BAD > -cross-gcc4.8: OK > Some of these don't seem to want to rmmod after they've been inserted. > Argh reboots. Do we really need to go any further than this to say conclusively that this is a compiler problem? It's clearly not a problem with the C code in that some compilers produce working code.... i.e. what steps do we need to take to get -cross-gcc4.[67] blacklisted when it comes to building ARM kernels? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs