Re: [Xen-devel] [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/07/2015 11:16 AM, Boris Ostrovsky wrote:
> On 07/07/2015 11:08 AM, Ian Campbell wrote:
> > On Tue, 2015-07-07 at 10:55 -0400, Boris Ostrovsky wrote:
> > > On 07/07/2015 03:39 AM, Ian Campbell wrote:
> > > > On Mon, 2015-07-06 at 12:06 -0400, Boris Ostrovsky wrote:
> > > > > > Bisection was broken for linux-3.18 until this morning, Ian fixed 
> > > > > > the
> > > > > > config and it should pick up on this failure and start investigating
> > > > > > once the next flight completes (tonight some time).
> > > > > OK, I'll wait until tomorrow then to see if it (the bisection) is
> > > > > successful.
> > > > After flight 59075 failed it has now started, progress is recorded at:
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-amd64-xl-pvh-intel.guest-start.html 
> > > >
> > > > It's currently reproducing the baseline pass (the double line around a
> > > > cell indicates what it is currently testing). The hashes in each cell
> > > > are in the same order as the tree list at the top, i.e Linux is the
> > > > first entry and Xen is the last.
> > > >
> > > > Scheduling wise I don't think it is going to have made very much
> > > > progress by the time you get in today though.
> > > So it is bisecting all five trees, right? (Well, four -- firmware 
> > > hashes
> > > don't seem to be changing).
> > Correct.
> >
> > > And if I assume that the issue is with kernel (which may not be a good
> > > assumption, but for the sake of my understanding of how the graph 
> > > works)
> > > then d048c068d00d (green) was good and ea5dd38e93b3 (red) is bad?
> > Correct.
> >
> > >   What
> > > about the one right below red (d24b9b8d95f0) --- is it bad or good?
> > Gray means not yet tested, so we don't know.
> >
> > Once it has established the baseline pass and fail by repeating each of
> > those three times then it will start testing things in the middle of the
> > graph and narrowing it down until it can identify the bad commit. I'd
> > expect this to take a few days at this point.
> OK, I think I'll try bisecting kernel myself then (if I can reproduce 
> this locally).

I didn't need to bisect this, the bad commit is 63753fac67. I am 
actually surprised this went into a stable kernel since that patch was a 
performance improvement (a not a huge one at that, I suspect).
Anyway, this kernel needs 5054daa285 from upstream.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel