[Top] [All Lists]

Re: Read corruption on ARM

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Read corruption on ARM
From: Jason Detring <detringj@xxxxxxxxx>
Date: Wed, 27 Feb 2013 10:28:07 -0600
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5/eKFndaISre2PgX0eYk/qdn3x5MBajj6/D1uiCXQTU=; b=x6lC6BcmIe1kstxwBEhBAIivILxzrRxUQVy3UYwMuX5CC/bfPv2jptd1X9U0XNeYHC NMtU2/TRm0fMj6R0bL7ZiKmeSr42Y8TcZxMTmF2ntpLar344hP9pY7gy5m+f/ip9FumM 2tFIBO+yrERrDk+Vu+Uz17bn1gufifRfYvkT2Let+Is9yELtv2SHSavn9rLkWTl7wZ36 ZfeC6R7Bq39zPJHtOndm+8fB+O+0Tx5qf/Ctg30llUo8tZ92oBbXf0NfJKOZcigCZNGQ ZPFoH8StWn0mHpM10Ytpa+iU53vlWF0WPNpljBh0F6CZQhnwyr7EA9v2bIrQKXoQ8PGA RwQg==
In-reply-to: <512D49E2.40003@xxxxxxxxxxx>
References: <CA+AKrqBQ=VG0oVsai+agywDKRgO9cG9AvT6mCTSZxKO3Si5Aiw@xxxxxxxxxxxxxx> <512D3856.5050305@xxxxxxxxxxx> <CA+AKrqC+6nXuCxdY08MBLsjv1fOPJ6=1ruTHsfGqxosQmCi_jQ@xxxxxxxxxxxxxx> <512D49E2.40003@xxxxxxxxxxx>
On 2/26/13, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> On 2/26/13 5:25 PM, Jason Detring wrote:
>> On 2/26/13, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>>> Enabling the trace_xfs_da_btree_corrupt tracepoint might yield more
>>> info, can you do that?
>>> I think it's:
>>> # trace-cmd -e xfs_da_btree_corrupt &
>>> # <do your dir read>
>>> # fg
>>> # ^C (ctrl-c trace-cmd)
>>> # trace-cmd report
>>> We might get more info about the buffer in question that way.
>> I'll give it a go, but it might take me a while to get back to you.
>> I'm not familiar with that tool, and it looks like it's not part of my
>> base install.
> You can also use sysfs/debugfs to do it:
> This should do it:
> # mount -t debugfs none /sys/kernel/debug
> # echo 1 > /sys/kernel/debug/tracing/tracing_enabled
> # echo 1 > /sys/kernel/debug/tracing/events/xfs/xfs_da_btree_corrupt/enable
> <run your failing run>
> # cat /sys/kernel/debug/tracing/trace

I'm switching to the RasPi for my tests since that seems to be
least-common-denominator hardware.  Logs attached for both sysfs and
trace-cmd runs.  They seem pretty sparse, though.

I tested with an end-to-end GCC 4.7.2 build.  Of interest is that
xfs.ko only seems to break when compiled as -O2.  Both -O1 and -Os
work without issue.  I wasn't able to test -O0 since the compiler
can't make it meet asm constraints when tracing is enabled.  Without
tracing, -O0 builds and runs without problems.

The test results, kernel configuration, spare xfs.ko modules, and
build logs are beneath
if you want to grab the entire directory.


Attachment: tracecmd-dmesg.txt
Description: Text document

Attachment: trace.dat
Description: Binary data

Attachment: tracecmd-report.txt
Description: Text document

Attachment: sysfstrace-dmesg.txt
Description: Text document

Attachment: sysfstrace-report.txt
Description: Text document

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