From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Jason Detring <detringj@gmail.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Read corruption on ARM
Date: Thu, 28 Feb 2013 20:53:15 -0600 [thread overview]
Message-ID: <5130181B.5050807@sandeen.net> (raw)
In-Reply-To: <20130301022539.GR5551@dastard>
On 2/28/13 8:25 PM, Dave Chinner wrote:
> On Thu, Feb 28, 2013 at 03:38:51PM -0600, Jason Detring wrote:
>> On 2/27/13, Eric Sandeen <sandeen@sandeen.net> 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
>>>>>
>>>>> <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?
>>
>> 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
>> <http://www.splack.org/~jason/projects/xfs-arm-corruption/3.6.11-g89caf39/>
>> 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?
Yeah, agreed. (FWIW, I had misunderstood earlier; it's not a
cross-compile problem, it sounds like any native or cross compile
with 4.6 or 4.7 above a certain optimization level fails).
We could be helpful by tracking down the problem perhaps, but if it
is already fixed, perhaps no reason to do so (unless it was an
accidental fix that might show up again)
I suppose we could do something like :
#if defined(__arm__) && if __GNUC__ == 4 && (__GNUC_MINOR__ == 6 || __GNUC_MINOR__ == 7)
#warning gcc-4.[67] is known to miscompile xfs on arm. A different compiler version is recommended.
#endif
The curious side of me still wants to track down what failed. ;) Maybe weekend work.
-Eric
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-01 2:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-26 21:58 Read corruption on ARM Jason Detring
2013-02-26 22:33 ` Eric Sandeen
2013-02-26 23:25 ` Jason Detring
[not found] ` <512D49E2.40003@sandeen.net>
[not found] ` <CA+AKrqCrphO-eKy0n=70O9hmB3mXttOsKmTdfRnPxgJM3_PAkQ@mail.gmail.com>
2013-02-27 17:00 ` Eric Sandeen
[not found] ` <CA+AKrqDq5xCNQo1X=MeRBq54ka0FGJEV5Rn6OzwY7eBfJ+8Wkw@mail.gmail.com>
2013-02-27 21:10 ` Eric Sandeen
[not found] ` <512E89C2.9000302@sandeen.net>
[not found] ` <CA+AKrqDaY4cgP+EPLepzUOU2jAOygTuj-0xDtOaGf+O0aRZV_g@mail.gmail.com>
[not found] ` <512E903A.2020405@sandeen.net>
[not found] ` <CA+AKrqAv7-5gGj_cNBNj=-nChKPzi+_HZmH=z2UABG9pDOmpBg@mail.gmail.com>
2013-02-28 4:38 ` Eric Sandeen
2013-02-28 4:50 ` Eric Sandeen
2013-02-28 5:27 ` Eric Sandeen
2013-02-28 21:38 ` Jason Detring
2013-03-01 2:25 ` Dave Chinner
2013-03-01 2:53 ` Eric Sandeen [this message]
2013-03-01 4:54 ` Dave Chinner
2013-02-26 22:37 ` Eric Sandeen
2013-02-26 22:51 ` Eric Sandeen
2013-02-26 23:21 ` Jason Detring
2013-02-27 2:16 ` Dave Chinner
2013-02-27 14:48 ` Eric Sandeen
2013-02-27 7:19 ` Stefan Ring
2013-02-27 14:48 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5130181B.5050807@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.com \
--cc=detringj@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox