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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

The other colours I think you might see are yellow, which means
unreliable (i.e. not failing of passing consistently) which will
probably result in the bisector giving up and blue which means blocked
which means we cannot test this revision because something failed prior
to the step which being bisected (i.e. failed to build or boot Xen, so
can't tell if the guest-start would work or not), in which case the
bisector will keep trying commits.

Ian.


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