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

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

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