[Top] [All Lists]

Re: Read corruption on ARM

To: Jason Detring <detringj@xxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: Read corruption on ARM
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 27 Feb 2013 22:38:15 -0600
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CA+AKrqAv7-5gGj_cNBNj=-nChKPzi+_HZmH=z2UABG9pDOmpBg@xxxxxxxxxxxxxx>
References: <CA+AKrqBQ=VG0oVsai+agywDKRgO9cG9AvT6mCTSZxKO3Si5Aiw@xxxxxxxxxxxxxx> <512D3856.5050305@xxxxxxxxxxx> <CA+AKrqC+6nXuCxdY08MBLsjv1fOPJ6=1ruTHsfGqxosQmCi_jQ@xxxxxxxxxxxxxx> <512D49E2.40003@xxxxxxxxxxx> <CA+AKrqCrphO-eKy0n=70O9hmB3mXttOsKmTdfRnPxgJM3_PAkQ@xxxxxxxxxxxxxx> <512E3BB2.6060407@xxxxxxxxxxx> <CA+AKrqDq5xCNQo1X=MeRBq54ka0FGJEV5Rn6OzwY7eBfJ+8Wkw@xxxxxxxxxxxxxx> <512E7639.20205@xxxxxxxxxxx> <512E89C2.9000302@xxxxxxxxxxx> <CA+AKrqDaY4cgP+EPLepzUOU2jAOygTuj-0xDtOaGf+O0aRZV_g@xxxxxxxxxxxxxx> <512E903A.2020405@xxxxxxxxxxx> <CA+AKrqAv7-5gGj_cNBNj=-nChKPzi+_HZmH=z2UABG9pDOmpBg@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
On 2/27/13 8:57 PM, Jason Detring wrote:
> On 2/27/13, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>> On 2/27/13 4:56 PM, Jason Detring wrote:
>>> On 2/27/13, Eric Sandeen <sandeen@xxxxxxxxxxx> 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 

<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.


> 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

<Prev in Thread] Current Thread [Next in Thread>