public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox