Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemuu-winxpsp3-vcpus1

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1"):
> On 01.03.17 at 06:37, <osstest-admin@xxxxxxxxxxxxxx> wrote:
> > *** Found and reproduced problem changeset ***
...> > 
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  1a6e3220cc19b8705c27ca90dbc615270237f372
> >   Bug not present: 0f72f9ba1f0586afac67bc88f35eba5cc26392cd
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106286/ 
> > 
> > 
> >   commit 1a6e3220cc19b8705c27ca90dbc615270237f372
> >   Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> >   Date:   Thu Feb 2 12:51:39 2017 +0100
> 
> Was the bisector possibly misguided here? The history of the test
> shows a pass of it on chardonnay1 on Feb 8, and the current
> xen-boot failure of this test (just like others) is due to Daniel's
> "efi: create new early memory allocator".

I think the bisector has, additionally, discovered a genuine bug which
happens to have been fixed in the meantime.  It will have used as a
passing baseline the last time that step passed _on that host_.

The flight on the 8th of February, 105648, had a broken step in it.
The bisector doesn't like such flights.  It prefers a non-broken
baseline.  It chose 104126 from the 11th of January.

After that, obviously, given an old baseline, bisection can easily
rediscover a since-fixed bug.

The reason for excluding flights with broken steps is that broken
steps can cause other parts of the flight not to run at all, so that
the data for the flight is not reliable enough for bisection.  At
least, that is my recollection of why that is.  I haven't done a
detailed analysis.

Ian.

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