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 configurations? 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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html