From: xen.org <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-4.0-testing test] 7433: regressions - FAIL
Date: Mon, 30 May 2011 18:43:15 +0100 [thread overview]
Message-ID: <osstest-7433-mainreport@xen.org> (raw)
flight 7433 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/7433/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-pair 16 guest-start fail REGR. vs. 7316
test-amd64-i386-pv 9 guest-start fail REGR. vs. 7316
test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 7316
test-amd64-i386-xl 9 guest-start fail REGR. vs. 7316
test-i386-i386-pair 16 guest-start fail REGR. vs. 7316
test-i386-i386-pv 9 guest-start fail REGR. vs. 7316
test-i386-i386-xl 9 guest-start fail REGR. vs. 7316
Tests which are failing intermittently (not blocking):
test-amd64-xcpkern-i386-xl-credit2 9 guest-start fail pass in 7416
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 7 windows-install fail never pass
test-amd64-amd64-xl 15 guest-stop fail never pass
test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-credit2 5 xen-boot fail like 7316
test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass
test-amd64-xcpkern-i386-pv 18 leak-check/check fail like 7316
test-amd64-xcpkern-i386-rhel6hvm-amd 7 redhat-install fail never pass
test-amd64-xcpkern-i386-rhel6hvm-intel 7 redhat-install fail never pass
test-amd64-xcpkern-i386-win 16 leak-check/check fail never pass
test-amd64-xcpkern-i386-xl-multivcpu 15 guest-stop fail never pass
test-amd64-xcpkern-i386-xl-win 7 windows-install fail never pass
test-amd64-xcpkern-i386-xl 15 guest-stop fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 7 windows-install fail never pass
test-i386-xcpkern-i386-win 16 leak-check/check fail never pass
test-i386-xcpkern-i386-xl 15 guest-stop fail never pass
version targeted for testing:
xen b11ae09ae58b
baseline version:
xen 5054ed412032
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <Ian.Campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jim Fehlig <jfehlig@novell.com>
Keir Fraser <keir@xen.org>
------------------------------------------------------------
jobs:
build-i386-xcpkern pass
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 fail
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-xcpkern-i386-xl fail
test-i386-xcpkern-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-xcpkern-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-xcpkern-i386-xl-credit2 fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-xcpkern-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-xcpkern-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-i386-i386-pair fail
test-amd64-xcpkern-i386-pair pass
test-i386-xcpkern-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv fail
test-i386-i386-pv fail
test-amd64-xcpkern-i386-pv fail
test-i386-xcpkern-i386-pv pass
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-xcpkern-i386-win fail
test-i386-xcpkern-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-xcpkern-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: 21503:b11ae09ae58b
tag: tip
user: Ian Campbell <ian.campbell@citrix.com>
date: Sat May 28 09:29:40 2011 +0100
IOMMU: Fail if intremap is not available and iommu=required/force.
Rather than sprinkling panic()s throughout the setup code hoist the
check up into common code.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23402:f979a1a69fe3
xen-unstable date: Thu May 26 08:18:44 2011 +0100
changeset: 21502:5768b9b19aaf
user: Markus Gross <gross@univention.de>
date: Sat May 28 09:28:28 2011 +0100
libxc: obtain correct length of p2m during core dumping
while implementing core dumping functionality for the libxl driver
of libvirt, I discovered an issue with mapping pages of a pv guest.
After dumping the core of a pv guest the domain was not cleared up
properly and some pages were not unmapped. This issue is similar
to the one reported here:
http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01314.html
In xc_domain_dumpcore_via_callback in the file xc_core.c the function
xc_core_arch_map_p2m is called to map P2M_FL_ENTRIES pages to the
variable p2m.
But to unmap the pages later, the dinfo->p2m_size has to be set
accordingly.
This was not done, instead a variable named p2m_size was set.
This way P2M_FL_ENTRIES was always zero and the pages were left
mapped.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen-unstable changeset: 23374:8bd7b5e98f2a
xen-unstable date: Tue May 24 15:00:16 2011 +0100
changeset: 21501:3220df717f10
user: Jim Fehlig <jfehlig@novell.com>
date: Sat May 28 09:26:32 2011 +0100
libxc: after saving, unmap correct amount for live_m2p
With some help from Olaf, I've finally got to the bottom of an issue I
came across while trying to implement save/restore in the libvirt
libxenlight driver. After issuing the save operation, the saved
domain was not being cleaned up properly and left in this state from
xl's perspective
xen33:# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 6821 8 r----- 122.5
(null) 2 2 2 --pssd 10.8
Checking the libvirtd /proc/$pid/maps I found this
7f3798984000-7f3798b86000 r--s 00002000 00:03 4026532097
/proc/xen/privcmd
So not all all pages belonging to the domain were unmapped from
libvirtd. In tools/libxc/xc_domain_save.c we found that
P2M_FL_ENTRIES were being mapped but only P2M_FLL_ENTRIES were being
unmapped. The attached patch changes the unmapping to use the same
P2M_FL_ENTRIES macro. I'm not too familiar with this code though so
posting here for review.
I suspect this was not noticed before since most (all?) processes
doing save terminate after the save and are not long-running like
libvirtd.
Ian Campbell writes:
> Looks like I introduced this in 18558:ccf0205255e1, sorry!
>
> I guess it is also wrong in the error path out of map_and_save_p2m_table
> and so we also need [another hunk].
This change should be backported to relevant earlier trees. -iwj
From: Jim Fehlig <jfehlig@novell.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>
Acked-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>
xen-unstable changeset: 23373:171007b4e2c4
xen-unstable date: Tue May 24 14:50:00 2011 +0100
changeset: 21500:5054ed412032
user: Keir Fraser <keir@xen.org>
date: Tue May 24 08:21:48 2011 +0100
Added signature for changeset d4cefc444b74
(qemu changes not included)
reply other threads:[~2011-05-30 17:43 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-7433-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.