Re: Read corruption on ARM

Jason Detring
2013-02-26T23:21:21Z

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.

Jason