Re: Read corruption on ARM

[Eric Sandeen <sandeen@sandeen.net>]

On 2/27/13 8:57 PM, Jason Detring wrote:
> On 2/27/13, Eric Sandeen <sandeen@sandeen.net> wrote:
>> On 2/27/13 4:56 PM, Jason Detring wrote:
>>> On 2/27/13, Eric Sandeen <sandeen@sandeen.net> wrote:
>>>> Can you send xfs.ko's from both native & cross-compiles?  Need debugging
>>>> info in the binaries (nonstripped)
>>>
>>> I don't have a native build, sorry :-(   I can put one together if
>>> necessary, but it will be quite a while on the Pi.
>>
>> Yah I found that out ;)  You could just make M=fs/xfs though?
> 
> Done.  These are also on the site at
>   <http://www.splack.org/~jason/projects/xfs-arm-corruption/tracetest/3.6.11-g89caf39/>
> The directory containing cross-compiled modules has been renamed
> xfs-modules-cross/ and the new natively built modules are beneath the
> xfs-modules-native/ directory.

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

<manual sort>

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?

the others differ:

349f3490a49f2ce539c2b058914f64f0  native/xfs-Os-g.ko.dis
91c8e8230774808b538c21a83106a5d7  cross/xfs-Os-g.ko.dis

649338e1b8eeed6a294504fc76a39cb0  native/xfs-O2-g.ko.dis
e52c2a48277326c313bba76aa0b33ab7  cross/xfs-O2-g.ko.dis

The diff of the disassembly of the others is huge, hard to
know where to start just yet.  Need an objdump mode that only
shows function-relative addresses or something to cut down
on the noise.

-Eric

> Slackware ARM (-current) also uses GCC 4.7.2 as its native compiler.
> The test modules built with it at -O2 are failing to read the
> ruby/1.9.1/ directory as well.  I don't know if that's fortunate (my
> homebrew compilers are just as good or bad as the distro's?) or
> unfortunate (I still have the problem and now I am diverging from your
> native RPi results that worked).
> 
> Is there maybe a memory or I/O tunable in the kernel .config that I've
> clobbered?
> 
> Jason
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs