From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom drive
Date: Wed, 8 Jun 2016 19:01:00 +0100 [thread overview]
Message-ID: <20160608180100.GG28116@citrix.com> (raw)
In-Reply-To: <20160607162914.GS25922@citrix.com>
On Tue, Jun 07, 2016 at 05:29:14PM +0100, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 02:58:05PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom drive"):
> > > This can only go in after the bug is fixed and possibly backported to all the
> > > trees we care about. It won't pass osstest self pushgate otherwise.
> >
> > I pushed these but they broke, but only with XSM. See, for example:
> >
> > From: osstest service owner <osstest-admin@xenproject.org>
> > To: <osstest-admin@xenproject.org>
> > Subject: [osstest test] 95322: regressions - FAIL
> > Date: Mon, 6 Jun 2016 19:29:51 +0000
> >
> > flight 95322 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/95322/
> >
> > 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 9 debian-hvm-install fail REGR. vs. 93413
> > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 93413
> >
> > I haven't had a chance to look at why, yet. For now, I have dropped
> > these patches from the osstest push gate.
> >
>
> I would say it is more related to stubdom.
>
> libxl: error: libxl_dm.c:1967:stubdom_xswait_cb: Stubdom 4 for 3 startup: startup timed out
> libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x219b2d8: deregister unregistered
> libxl: error: libxl_create.c:1422:domcreate_devmodel_started: device model did not start: -9
>
> I've put this on my list and will investigate further.
I know why.
The backend for empty CDROM is always in state 1. Mini-OS blkfront
refuses to move forward unless the backend status turns 4. See
mini-os.git blkfront.c:init_blkfront.
I'm not entirely sure how to fix it though.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-06-08 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 16:20 [PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom drive Wei Liu
2016-04-06 16:20 ` [PATCH OSSTEST v2 1/2] TestSupport: rename guest_editconfig_nocd to _midinstall Wei Liu
2016-04-06 16:20 ` [PATCH OSSTEST v2 2/2] Make guest cdrom empty after installation completes Wei Liu
2016-06-07 13:58 ` [PATCH OSSTEST v2 0/2] Test booting hvm guest with empty cdrom drive Ian Jackson
2016-06-07 16:29 ` Wei Liu
2016-06-08 18:01 ` Wei Liu [this message]
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=20160608180100.GG28116@citrix.com \
--to=wei.liu2@citrix.com \
--cc=Ian.Jackson@eu.citrix.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).