From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <ian.jackson@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [xen-4.6-testing test] 137064: regressions - FAIL
Date: Mon, 17 Jun 2019 08:06:30 -0600 [thread overview]
Message-ID: <5D079E660200007800238D4A@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <23793.763.56062.488960@mariner.uk.xensource.com>
>>> On 31.05.19 at 12:33, <ian.jackson@citrix.com> wrote:
> osstest service owner writes ("[xen-4.6-testing test] 137064: regressions -
> FAIL"):
>> flight 137064 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/137064/
>>
>> Regressions :-(
>
> This is all pretty bad but I think it is mostly new tests in XTF,
> incompatibility with stretch, etc.
>
> The only reason we are running this test at all is to get various
> build fixes included in the stable-4.6 branch so that we can test
> 4.6-to-4.7 migration.
>
> Accordingly, unless someone objects, I will force push this.
Fundamentally I don't care overly much about this old tree, but
I can't figure how you came to the "mostly new tests in XTF"
conclusion. In fact ...
>> version targeted for testing:
>> xen 7f54219572caced98a133072546ad890897b9827
>> baseline version:
>> xen 3636de3f1a9a513ebdcd77555dce0e4d451e198b
>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 127792
>> test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 127792
>> test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 127792
>> test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 127792
>> test-xtf-amd64-amd64-5 108 leak-check/check fail REGR. vs. 127792
>> test-xtf-amd64-amd64-1 108 leak-check/check fail REGR. vs. 127792
>> test-xtf-amd64-amd64-4 108 leak-check/check fail REGR. vs. 127792
>> test-xtf-amd64-amd64-3 108 leak-check/check fail REGR. vs. 127792
>> test-xtf-amd64-amd64-2 108 leak-check/check fail REGR. vs. 127792
... these are all XTF related ones, and leak-check failures imo aren't
liable to be related to "new" XTF tests. Otoh I think leak-check failures
are sufficiently "fine" to ignore, and hence aren't an argument against
a force push.
>> test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 127792
>> test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 127792
>> test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 127792
>> test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 127792
>> build-armhf 6 xen-build fail REGR. vs. 127792
>> test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 127792
>> test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 127792
I'm far more worried about all these guest install failures - it can't
really help to ignore them by way of doing a force push. Without
having looked, quite likely they're (almost) all the same hvmloader
issue as diagnosed on the 4.7 branch. If so, waiting for the tests
to actually succeed would seem better to me.
To give osstest some relief, would it be possible to temporarily
disable testing of the older trees (which we know won't succeed)?
They could be incrementally re-enabled from oldest onwards once
we know the -prev build issues have been addressed in the
respective N-1 tree.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-17 14:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 1:00 [xen-4.6-testing test] 137064: regressions - FAIL osstest service owner
2019-05-31 1:00 ` [Xen-devel] " osstest service owner
2019-05-31 10:33 ` Ian Jackson
2019-05-31 10:33 ` [Xen-devel] " Ian Jackson
2019-06-17 14:06 ` Jan Beulich [this message]
2019-06-17 14:29 ` Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5D079E660200007800238D4A@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=ian.jackson@citrix.com \
--cc=jgross@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).