From: xen.org <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-4.1-testing test] 7418: regressions - FAIL
Date: Mon, 30 May 2011 05:58:25 +0100 [thread overview]
Message-ID: <osstest-7418-mainreport@xen.org> (raw)
flight 7418 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/7418/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-pair 16 guest-start fail REGR. vs. 7329
test-amd64-i386-pv 9 guest-start fail REGR. vs. 7329
test-amd64-i386-xl-multivcpu 9 guest-start fail REGR. vs. 7329
test-amd64-i386-xl 9 guest-start fail REGR. vs. 7329
test-i386-i386-pv 9 guest-start fail REGR. vs. 7329
test-i386-i386-xl 9 guest-start fail REGR. vs. 7329
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-credit2 8 debian-fixup fail pass in 7405
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 13 guest-stop fail never pass
test-amd64-i386-rhel6hvm-amd 7 redhat-install fail like 7318
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail like 7313
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-win-vcpus1 13 guest-stop fail never pass
test-amd64-xcpkern-i386-rhel6hvm-amd 8 guest-saverestore fail never pass
test-amd64-xcpkern-i386-rhel6hvm-intel 8 guest-saverestore fail never pass
test-amd64-xcpkern-i386-win 16 leak-check/check fail never pass
test-amd64-xcpkern-i386-xl-win 13 guest-stop fail never pass
test-i386-i386-pair 16 guest-start fail like 7313
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-i386-xcpkern-i386-win 16 leak-check/check fail never pass
version targeted for testing:
xen dbe9e02a1f75
baseline version:
xen 61336bbb0002
------------------------------------------------------------
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>
Li, Xin <xin.li@intel.com>
Tim Deegan <Tim.Deegan@citrix.com>
Yang, Wei <wei.y.yang@intel.com>
------------------------------------------------------------
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 pass
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-xcpkern-i386-xl pass
test-i386-xcpkern-i386-xl pass
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 pass
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 pass
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 pass
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: 23069:dbe9e02a1f75
tag: tip
user: Yang, Wei <wei.y.yang@intel.com>
date: Sat May 28 09:22:55 2011 +0100
x86/intel: Fix CPUID leaf 7 detection
Must set subleaf to 0 (input ECX==0).
Signed-off-by: Yang, Wei <wei.y.yang@intel.com>
Signed-off-by: Li, Xin <xin.li@intel.com>
xen-unstable changeset: 23436:f6ce871e5689
xen-unstable date: Sat May 28 08:57:12 2011 +0100
changeset: 23068:3f2f2543e943
user: Keir Fraser <keir@xen.org>
date: Sat May 28 09:17:15 2011 +0100
Clean up stdarg handling a little. Fix for NetBSD.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23432:14eb8e1fcd82
xen-unstable date: Fri May 27 15:49:24 2011 +0100
changeset: 23067:f408456e30e8
user: Ian Campbell <ian.campbell@citrix.com>
date: Sat May 28 09:16:08 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: 23066:d0feff6ff44c
user: Markus Gross <gross@univention.de>
date: Sat May 28 09:09:40 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: 23065:41fcee15368a
user: Jim Fehlig <jfehlig@novell.com>
date: Sat May 28 09:08:21 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: 23064:61336bbb0002
user: Tim Deegan <Tim.Deegan@citrix.com>
date: Tue May 24 08:19:39 2011 +0100
drivers/passthrough: fix error paths in pci_add_device*()
When a device can't be allocated to dom0 by the IOMMU, don't leave
dom0 in the "domain" field. It causes pci_remove_device()
to crash trying to remove the dev from the domain's list of devices
(and was probably the wrong thing to do anyway).
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23371:4326bcd88b33
xen-unstable date: Mon May 23 18:35:32 2011 +0100
drivers/passthrough: Revert 23352:ea48976517af -- incorrect bugfix.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 23370:2e6719425265
xen-unstable date: Mon May 23 18:35:04 2011 +0100
(qemu changes not included)
reply other threads:[~2011-05-30 4:58 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-7418-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.