I tried git bisect and it ended up in a qla2xxx fix (and I do not even
have qlogic card in that system).
I did it couple more times and landed on different patches.
My latest (fourth ot fifth, I forgot :) bisect landed on the patch with
commit 546a1924224078c6f582e68f890b05b387b42653 ( writeback:
write_cache_pages doesn't terminate at nr_to_write <= 0)
I verified that this is valid patch by running the test script 180 for
nearly 500 times on the tree just prior to this patch.
On Thu, 2011-06-16 at 16:29 -0500, Alex Elder wrote:
> On Tue, 2011-06-14 at 11:51 -0700, Chandra Seetharaman wrote:
> > Hello All,
> > test case 180 fails often (4 out of 5) in my x86_64 system.
> > Any suggestions on how to proceed to debug ?
> I have been seeing failures like that sometimes
> (more often recently I think) for a while. I
> have not had the chance to really chase it down.
> If you can reproduce it pretty relibly you could
> use "git bisect" to try to find out whether the
> failures started to occur after a particular
> > regards,
> > chandra
> > 80 176s ... - output mismatch (see 180.out.bad)^M
> > --- 180.out 2011-04-20 08:34:36.000000000 -0700^M
> > +++ 180.out.bad 2011-06-03 14:10:45.000000000 -0700^M
> > @@ -1 +1,4 @@^M
> > QA output created by 180^M
> > +file /mnt/xfsScratchMntPt/656 has incorrect size - sync failed^M
> > +file /mnt/xfsScratchMntPt/818 has incorrect size - sync failed^M
> > +file /mnt/xfsScratchMntPt/899 has incorrect size - sync failed^M
> > Ran: 180^M
> > Failures: 180^M
> > Failed 1 of 1 tests^M
> > _______________________________________________
> > xfs mailing list
> > xfs@xxxxxxxxxxx
> > http://oss.sgi.com/mailman/listinfo/xfs