|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.3-testing test] 63803: regressions - trouble: blocked/broken/fail/pass
flight 63803 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 63212 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 3 host-install(3) broken in 63738 pass in 63803 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken in 63738 pass in 63803 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken pass in 63700 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail in 63700 pass in 63803 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 63738 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-localmigrate/x10 fail pass in 63738 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 63738 like 63212 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-i386-rumpuserxen 6 xen-build fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-build fail never pass test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 6 xen-boot fail never pass test-armhf-armhf-libvirt 6 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 6 xen-boot fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-libvirt-raw 6 xen-boot fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 6 xen-boot fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl 6 xen-boot fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/check fail never pass version targeted for testing: xen e875e0e5fcc5912f71422b53674a97e5c0ae77be baseline version: xen 85ca813ec23c5a60680e4a13777dad530065902b Last test of basis 63212 2015-10-22 10:03:01 Z 18 days Failing since 63360 2015-10-29 13:39:04 Z 10 days 8 attempts Testing same since 63381 2015-10-30 18:44:54 Z 9 days 7 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale fail test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck fail test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 blocked test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel broken test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-migrupgrade fail test-amd64-i386-migrupgrade fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail test-amd64-i386-xend-qemut-winxpsp3 fail test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-step test-amd64-i386-qemuu-rhel6hvm-intel host-install(3) Not pushing. ------------------------------------------------------------ commit e875e0e5fcc5912f71422b53674a97e5c0ae77be Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Oct 21 16:18:30 2015 +0100 libxl: adjust PoD target by memory fudge, too PoD guests need to balloon at least as far as required by PoD, or risk crashing. Currently they don't necessarily know what the right value is, because our memory accounting is (at the very least) confusing. Apply the memory limit fudge factor to the in-hypervisor PoD memory target, too. This will increase the size of the guest's PoD cache by the fudge factor LIBXL_MAXMEM_CONSTANT (currently 1Mby). This ensures that even with a slightly-off balloon driver, the guest will be stable even under memory pressure. There are two call sites of xc_domain_set_pod_target that need fixing: The one in libxl_set_memory_target is straightforward. The one in xc_hvm_build_x86.c:setup_guest is more awkward. Simply setting the PoD target differently does not work because the various amounts of memory during domain construction no longer match up. Instead, we adjust the guest memory target in xenstore (but only for PoD guests). This introduces a 1Mby discrepancy between the balloon target of a PoD guest at boot, and the target set by an apparently-equivalent `xl mem-set' (or similar) later. This approach is low-risk for a security fix but we need to fix this up properly in xen.git#staging and probably also in stable trees. This is XSA-153. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (cherry picked from commit 56fb5fd62320eb40a7517206f9706aa9188d6f7b) (cherry picked from commit 423d2cd814e8460d5ea8bd191a770f3c48b3947c) Conflicts: tools/libxl/libxl_dom.c Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (cherry picked from commit 73b70e3c5d59e63126c890068ee0cbf8a2a3b640) commit 9f359c61e3927f94bb280ffb200155dd20465fda Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 29 14:28:33 2015 +0100 x86: rate-limit logging in do_xen{oprof,pmu}_op() Some of the sub-ops are acessible to all guests, and hence should be rate-limited. In the xenoprof case, just like for XSA-146, include them only in debug builds. Since the vPMU code is rather new, allow them to be always present, but downgrade them to (rate limited) guest messages. This is CVE-2015-7971 / XSA-152. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: 95e7415843b94c346e5ba8682665f508f220e04b master date: 2015-10-29 13:37:19 +0100 commit 7f28d311a80e9d33d8270d6fb7b949dd4eef37f0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 29 14:28:06 2015 +0100 xenoprof: free domain's vcpu array This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per guest"). This is CVE-2015-7969 / XSA-151. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: 6e97c4b37386c2d09e09e9b5d5d232e37728b960 master date: 2015-10-29 13:36:52 +0100 commit 2d330c121eff67f4828dc8536180986e0dfdf14b Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Oct 29 14:27:44 2015 +0100 x86/PoD: Eager sweep for zeroed pages Based on the contents of a guests physical address space, p2m_pod_emergency_sweep() could degrade into a linear memcmp() from 0 to max_gfn, which runs non-preemptibly. As p2m_pod_emergency_sweep() runs behind the scenes in a number of contexts, making it preemptible is not feasible. Instead, a different approach is taken. Recently-populated pages are eagerly checked for reclaimation, which amortises the p2m_pod_emergency_sweep() operation across each p2m_pod_demand_populate() operation. Note that in the case that a 2M superpage can't be reclaimed as a superpage, it is shattered if 4K pages of zeros can be reclaimed. This is unfortunate but matches the previous behaviour, and is required to avoid regressions (domain crash from PoD exhaustion) with VMs configured close to the limit. This is CVE-2015-7970 / XSA-150. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 101ce53266866144e724ed593173bc4098b300b9 master date: 2015-10-29 13:36:25 +0100 commit d7f7c5c6559ac3fa52dba5d8fe952b2c00f962db Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 29 14:27:02 2015 +0100 free domain's vcpu array This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per guest"). This is CVE-2015-7969 / XSA-149. Reported-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: d46896ebbb23f3a9fef2eb6066ae614fd1acfd96 master date: 2015-10-29 13:35:40 +0100 commit 3be91e6c200af155a1badefc5945008c8da12ce7 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 29 14:24:40 2015 +0100 x86: guard against undue super page PTE creation When optional super page support got added (commit bd1cd81d64 "x86: PV support for hugepages"), two adjustments were missed: mod_l2_entry() needs to consider the PSE and RW bits when deciding whether to use the fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK unconditionally. This is CVE-2015-7835 / XSA-148. Reported-by: "æ ¾å°?è?ª(好é£?)" <shangcong.lsc@xxxxxxxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: fe360c90ea13f309ef78810f1a2b92f2ae3b30b8 master date: 2015-10-29 13:35:07 +0100 commit fb02dec2d06a2dd104682973a21375795e344e25 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Oct 29 14:24:17 2015 +0100 arm: handle races between relinquish_memory and free_domheap_pages Primarily this means XENMEM_decrease_reservation from a toolstack domain. Unlike x86 we have no requirement right now to queue such pages onto a separate list, if we hit this race then the other code has already fully accepted responsibility for freeing this page and therefore there is no more for relinquish_memory to do. This is CVE-2015-7814 / XSA-147. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 1ef01396fdff88b1c3331a09ca5c69619b90f4ea master date: 2015-10-29 13:34:17 +0100 commit e06f1c36d36260b7d82f8563f1a6f226160d4b23 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Oct 29 14:23:35 2015 +0100 AMD Vi: fix HPET ID check Cherry picked from commit 2ca9fbd739 ("AMD IOMMU: allocate IRTE entries instead of using a static mapping") mainly to fix build with gcc 5.x. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> commit 39698f92e4185afdd956e9af6888923c27728875 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Thu Oct 29 14:10:31 2015 +0100 xen: common: Use unbounded array for symbols_offset. Using a singleton array causes gcc5 to report: symbols.c: In function 'symbols_lookup': symbols.c:128:359: error: array subscript is above array bounds [-Werror=array-bounds] symbols.c:136:176: error: array subscript is above array bounds [-Werror=array-bounds] Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 3f82ea62826d4eb06002d8dba475bafcc454b845 master date: 2015-03-20 12:02:03 +0000 ======================================== _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |