[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-4.5-testing test] 58276: regressions - FAIL



>>> On 10.06.15 at 05:28, <osstest@xxxxxxxxxxxxxxx> wrote:
> flight 58276 xen-4.5-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/58276/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
> 57908

I just looked at this and ...

> Regressions which are regarded as allowable (not blocking):
>  test-armhf-armhf-xl-sedf      6 xen-boot                  fail REGR. vs. 
> 57908
>  test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop              fail like 
> 57908
>  test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 
> 57908

... this another time: The former is on Intel, while the latter on AMD,
so unlikely (i.e. minus one of them being some random, unrelated
failure) to be host or even vendor specific. Since this test consists
of 10 migrations in a row, with guest liveliness only checked once at
the end, it's rather unlikely that we'll be able to tell anything from
looking at the logs taken at the end. Yet the guest not responding
to pings first of all raises the question of whether its interrupts are
somehow not arriving anymore as intended. Would it be possible to
look at such a guest in that final state to check whether e.g.
keyboard input / mouse movement still work? Or to take a series of
xenctx or xl vcpu-list outputs to see whether the guest is still doing
_something_ (i.e. not completely locked up)?

Also, has anyone with more tools/qemu/osstest knowledge than me
managed to gain at least some weak theory of where there might be
this qemuu dependency affecting _only_ the stable trees?

Jan



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.