[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |