From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Jason Detring <detringj@gmail.com>, xfs@oss.sgi.com
Subject: Re: Read corruption on ARM
Date: Wed, 27 Feb 2013 08:48:39 -0600 [thread overview]
Message-ID: <512E1CC7.9050100@sandeen.net> (raw)
In-Reply-To: <20130227021614.GZ5551@dastard>
On 2/26/13 8:16 PM, Dave Chinner wrote:
> On Tue, Feb 26, 2013 at 05:21:15PM -0600, Jason Detring wrote:
>> On 2/26/13, Eric Sandeen <sandeen@sandeen.net> wrote:
>>> On 2/26/13 4:37 PM, Eric Sandeen wrote:
>>>> On 2/26/13 3:58 PM, Jason Detring wrote:
>>>>> Hello list,
>>>>
>>>> <snip>
>>>>
>>>>> This also seems to impact the Raspberry Pi. Below shows a 256 MB test
>>>>> case filesystem.
>>>>> The filesystem was created on an x86-64 box by mkfs.xfs 3.1.8 and
>>>>> populated by kernel 3.6.9.
>>>>> This failure report is Linux 3.6.11-g89caf39 built by GCC 4.7.2 from
>>>>> <https://github.com/raspberrypi/linux/commits/rpi-3.6.y>
>>>>> The problem appears to be tied to the filesystem, not the media,
>>>>> since both an external USB reader and a loopback-mounted image on the
>>>>> unit's main SD media show the same backtrace. The loopback image was
>>>>> captured on other hardware, then copied onto the RPi via network.
>>>>
>>>> Missed this; let me fire up my pi and see if I can replicate it.
>>>
>>> Realized that I'll need to cross-compile xfs.ko I guess...
>>>
>>> But - do you see this when the *whole* kernel is cross-compiled?
>>> Building the kernel one way and xfs another way, with another gcc,
>>> is probably nothing but trouble. :)
>>
>> Yes, I did. I remember seeing it in months past when those compilers
>> were freshly released. I only mixed-and-matched here as a spot check
>> to be sure the errors were still present. For any Real Serious
>> Business, I'll build end-to-end with the same compiler.
>>
>> I've uploaded my demonstration problem file system here:
>> <http://www.splack.org/~jason/projects/xfs-arm-corruption/problemimage.xfs>
>> This throws a backtrace when "find ." is run on the mountpoint. The
>> junk in the file system is just that--filler. Don't take the kernel
>> archives as debugging builds.
>
> The filesystem image appears to be just fine. xfs_repair on x86_64 does
> not complain about it, nor does xfs_check. Mounting and running find
> on it on my current 3.8-dev kernel does not cause any problems,
> either. And looking directly at the structures on disk I can't see
> any obvious problems.
And works fine on my arm-compiled xfs.ko on my R-Pi.
> Hence whatever issue is being seen must be to do with the way the
> compiled ARM code is interpreting the on-disk structures....
s/compiled/cross-compiled/
-Eric
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-27 14:48 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
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 [this message]
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=512E1CC7.9050100@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.