[Top] [All Lists]

Re: Read corruption on ARM

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Read corruption on ARM
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 27 Feb 2013 08:48:39 -0600
Cc: Jason Detring <detringj@xxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130227021614.GZ5551@dastard>
References: <CA+AKrqBQ=VG0oVsai+agywDKRgO9cG9AvT6mCTSZxKO3Si5Aiw@xxxxxxxxxxxxxx> <512D390D.7060302@xxxxxxxxxxx> <512D3C71.1030100@xxxxxxxxxxx> <CA+AKrqACW65gAOHCOFsVZp790nGd=bjSZnSE18rHkAFPVy_y9Q@xxxxxxxxxxxxxx> <20130227021614.GZ5551@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
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@xxxxxxxxxxx> 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....



> Cheers,
> Dave.

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