From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [linux-3.18 test] 59041: regressions - trouble: blocked/broken/fail/pass Date: Tue, 07 Jul 2015 15:22:36 -0400 Message-ID: <559C26FC.8020902@oracle.com> References: <1436171567.25646.6.camel@citrix.com> <559A9D49.3020305@oracle.com> <1436197741.25646.121.camel@citrix.com> <559AA79D.6060808@oracle.com> <1436254763.17598.117.camel@citrix.com> <559BE87E.4050506@oracle.com> <1436281736.25646.240.camel@citrix.com> <559BED62.9060104@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559BED62.9060104@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Elena Ufimtseva , xen-devel@lists.xensource.com, Andrew Cooper , ian.jackson@eu.citrix.com, Jan Beulich , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org 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