From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [xen-4.5-testing test] 58276: regressions - FAIL Date: Wed, 10 Jun 2015 11:59:56 +0100 Message-ID: <1433933996.30003.30.camel@citrix.com> References: <5578241E0200007800082F47@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z2djp-0006QY-Hd for xen-devel@lists.xenproject.org; Wed, 10 Jun 2015 11:00:05 +0000 In-Reply-To: <5578241E0200007800082F47@mail.emea.novell.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: Jan Beulich Cc: xen-devel , ian.jackson@eu.citrix.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, 2015-06-10 at 10:48 +0100, Jan Beulich wrote: > >>> On 10.06.15 at 05:28, 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)? Osstest doesn't (AFAIK) have a mechanism for deciding to preserve a test machine upon failure for later fiddling with. The only choice would be to manually lock the machine and run adhoc reproduction until the issue occurred. > > 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@lists.xen.org > http://lists.xen.org/xen-devel