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
<http://www.splack.org/~jason/projects/xfs-arm-corruption/tracetest/>
if you want to grab the entire directory.
Jason
tracecmd-dmesg.txt
Description: Text document
trace.dat
Description: Binary data
tracecmd-report.txt
Description: Text document
sysfstrace-dmesg.txt
Description: Text document
sysfstrace-report.txt
Description: Text document
|