From: Jan Beulich <jbeulich@suse.com>
To: "Jürgen Groß" <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
osstest service owner <osstest-admin@xenproject.org>
Subject: Re: [xen-unstable test] 149520: regressions - FAIL
Date: Thu, 9 Apr 2020 12:35:33 +0200 [thread overview]
Message-ID: <d65728ee-5287-3e90-ef44-5c3bb8f6ed77@suse.com> (raw)
In-Reply-To: <f7298d04-ba2c-13cc-7f9b-f57e94340fe3@suse.com>
On 09.04.2020 12:23, Jürgen Groß wrote:
> On 09.04.20 11:00, Jan Beulich wrote:
>> On 09.04.2020 10:56, Jürgen Groß wrote:
>>> On 09.04.20 10:00, Jan Beulich wrote:
>>>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>>>> On 09.04.20 04:30, osstest service owner wrote:
>>>>>> flight 149520 xen-unstable real [real]
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>>>>>
>>>>>> Regressions :-(
>>>>>>
>>>>>> Tests which did not succeed and are blocking,
>>>>>> including tests which could not be run:
>>>>>> test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478
>>>>>> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478
>>>>>
>>>>> Is it possible to get the ioemu-stubdom binary used in those tests?
>>>>
>>>> Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
>>>> http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
>>>
>>> No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
>>> one. According to the log the path should be fine, but the file in no
>>> way matches the crashed one.
>>
>> Then look under http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
>> or any of the other http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
>> I'm pretty sure all produced binaries get collected and made available.
>
> Yes, there it could be found.
>
> I'm still struggling to understand why the stubdom is built as 32-bit
> binary for this test.
Aiui in test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
the first amd64 stands for the host (Xen) architecture, the
last for the guest one, and the i386 for the tool stack's. I
assume the stubdom binary chosen is picked based on the tool
stack properties, despite it running in a different domain.
Jan
next prev parent reply other threads:[~2020-04-09 10:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 2:30 [xen-unstable test] 149520: regressions - FAIL osstest service owner
2020-04-09 7:31 ` Jürgen Groß
2020-04-09 8:00 ` Jan Beulich
2020-04-09 8:56 ` Jürgen Groß
2020-04-09 9:00 ` Jan Beulich
2020-04-09 10:23 ` Jürgen Groß
2020-04-09 10:35 ` Jan Beulich [this message]
2020-04-09 12:34 ` Jürgen Groß
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=d65728ee-5287-3e90-ef44-5c3bb8f6ed77@suse.com \
--to=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=osstest-admin@xenproject.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.