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 11:16:50 -0400 Message-ID: <559BED62.9060104@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436281736.25646.240.camel@citrix.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: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. >