From: xen.org <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-unstable test] 9113: regressions - FAIL
Date: Wed, 28 Sep 2011 22:56:44 +0100 [thread overview]
Message-ID: <osstest-9113-mainreport@xen.org> (raw)
flight 9113 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9113/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-amd64-xl-sedf 11 guest-localmigrate fail REGR. vs. 9110
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen 7998217630e2
baseline version:
xen bfa65eb40b2a
------------------------------------------------------------
People who touched revisions under test:
Andreas Olsowski <andreas.olsowski@leuphana.de>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 23883:7998217630e2
tag: tip
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Sep 28 16:42:11 2011 +0100
libxl: attempt to cleanup tapdisk processes on disk backend destroy.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23882:72e3391299e4
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Sep 28 16:35:44 2011 +0100
libxl: correct allocation size in libxl_list_nics
The function returns a list of libxl_nicinfo not libxl_device_nic.
Causes memory corruption on free.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23881:8877da7ba3a4
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Sep 28 16:34:00 2011 +0100
libxl: correct allocation size in libxl_list_vm
*ptr has type libxl_vminfo not libxl_domid, so correct calloc call.
This the second instance of this bug I've noticed recently, I did a
quick audit of other similar uses of sizeof(...) and all I spotted
were a couple of harmlessly reversed calloc arguments. It's a pretty
strong argument for "foo = ..alloc(sizeof(*foo))" rather than
"alloc(sizeof(foos_type))" though...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23880:ba1afb9bc159
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Sep 28 16:32:31 2011 +0100
libxl: correctly propagate errors from libxl_domain_destroy
currently it return success e.g. even if xc_domain_destroy fails.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23879:8863be49d319
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Sep 28 16:31:11 2011 +0100
libxl: fail to parse disk vpath if a disk+part number needed but unavailable
libxl__device_disk_dev_number() can parse a virtpath which is an encoded
unsigned long but does not set *pdisk or *ppartition in that case.
Ideally we would parse the number but for now simply fail to prevent cascading
failures.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23878:59c7213b5949
user: Ian Campbell <ian.campbell@citrix.com>
date: Tue Sep 27 18:39:15 2011 +0100
libxl: do not try to redo incoming migration on reboot of migrated domain
After a migration, reboot was trying to receive another incoming
migration, instead of restarting the domain it already has.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Andreas Olsowski <andreas.olsowski@leuphana.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
changeset: 23877:bfa65eb40b2a
user: Ian Campbell <ian.campbell@citrix.com>
date: Tue Sep 27 18:03:11 2011 +0100
libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly
Instead of indirecting via libxl_device_model_starting. This fixes a
segmentation fault using stubdomains where starting->for_spawn is
(validly) NULL because starting a stubdom doesn't need to spawn a
process.
Most callers of libxl__wait_for_device_model already pass NULL for
this variable (because they are not on the starting path) so on
libxl__confirm_device_model_startup needs to change.
Reported-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
========================================
commit cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Jun 28 13:50:53 2011 +0100
qemu-char.c: fix incorrect CONFIG_STUBDOM handling
qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
reply other threads:[~2011-09-28 21:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=osstest-9113-mainreport@xen.org \
--to=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/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.