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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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).

Thanks (and to IanJ too).

-boris


>
> 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.
>