On Sun, Jun 02, 2013 at 11:04:11PM -0400, CAI Qian wrote:
> > There's memory corruption all over the place. It is most likely
> > that trinity is causing this - it's purpose is to trigger corruption
> > issues, but they aren't always immediately seen. If you can trigger
> > this xfs trace without trinity having been run and without all the
> > RCU/idle/scheduler/cgroup issues occuring at the same time, then
> > it's likely to be caused by XFS. But right now, I'd say XFS is just
> > an innocent bystander caught in the crossfire. There's nothing I can
> > do from an XFS persepctive to track this down...
> OK, this can be reproduced by just running LTP and then xfstests without
> trinity at all...
Cai, can you be more precise about what is triggering it? LTP and
xfstests do a large amount of stuff, and stack traces do not do not
help narrow down the cause at all. Can you provide the follwoing
information and perform the follwoing steps:
1. What xfstest is tripping over it?
2. Can you reproduce it just by running that one specific test
on a pristine system (i.e. freshly mkfs'd filesystems,
immediately after boot)
3. if you can't reproduce it like that, does it reproduce on
an xfstest run on a pristine system? If so, what command
line are you running, and what are the filesystem
4. if you cannot reproduce it just with xfstests and you need
to run LTP first, then can you just run the xfstest that
is failing after running LTP and see if that triggers the
problem. If it does, please take a metadump of the
filesystems after LTP has run, save them, and if the
single test then fails send me the metadumps and your
xfstests command line.
5. If all else fails, bisect the kernel to identify the
commit that introduces the problem....