Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-win7-amd64

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable bisection] complete 
test-amd64-amd64-xl-win7-amd64"):
> On Wed, 2012-06-20 at 14:43 +0100, Ian Jackson wrote:
> > The bisector has repro'd this on the same host with 6 tests:
> > alternately failures for 9d1fd58ff602 and successes for 32034d1914a6.
> 
> Which means it might be unrelated from that specific commit (sorry if
> it's a stupid question, just want to be sure I'm getting things
> correct :-/ )

No.  If it fails with 9d1fd58ff602 and succeeds with 32034d1914a6 then
9d1fd58ff602 is responsible because 32034d1914a6 is the only parent of
9d1fd58ff602.

> > So if it's a heisenbug we've been moderately (but not outrageously)
> > unlucky that it actually fingered a specific changeset rather than
> > just shrugging its shoulders and moving on.  (It does the latter quite
> > a lot.)
> 
> Just to be sure, this part of the bisector report:
> 
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-win7-amd64
> test windows-install
> 
> means that the test that failed was 'job
> test-amd64-amd64-xl-win7-amd64' (and, specifically, during
> 'windows-install' phase), right?

Yes.

> I'm asking because I actually found a bug in that change, _but_ it only
> comes into play if the SEDF scheduler is being used. In fact, this test
> also fails:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13053/test-amd64-amd64-xl-sedf/info.html
...
> 2012-06-16 07:37:47 Z executing ssh ... root@xxxxxxxxxxxxx xl create 
> /etc/xen/debian.guest.osstest.cfg
> libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: 
> Invalid argument
> libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build 
> domain: -3
> Parsing config from /etc/xen/debian.guest.osstest.cfg
> 
> Which is actually related to my patch, and for which I already have a
> fix ready.

Right.

> OTOH, I really don't see how that patch might cause that HVM windows
> domain to die, given the log for 'test-amd64-amd64-xl-sedf' says this:
> 
> Parsing config from /etc/xen/win.guest.osstest.cfg
> Daemon running with PID 2642
> 
> Which seems to mean, at least to me, that the check happened without
> causing any issues (as it, conversely, does when SEDF is the scheduler).

The failure of the non-sedf test is that Windows takes too long to
become ready.

If you look at this page:

  
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-xl-win7-amd64.windows-install.html

you can see what the bisector did.

Flights 13024, 13025, 13087, 13096 and 13103 used code built from 
32034d1914a6 and passed.

Flights 13095, 13102 and 13105 used code built from from 9d1fd58ff602
and failed.  These all used the builds from flight 13033, which was
another bisector run.

It is possible that the build in 13033 is broken somehow.
Xen and tools came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64/
Dom0 kernel came from here:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/13033/build-amd64-pvops/

Ian.

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