|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.2-testing test] 13920: regressions - FAIL
flight 13920 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 9 guest-start fail REGR. vs. 13912 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop 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-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop 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 version targeted for testing: xen a69c8e5c4afc baseline version: xen ca3e8190a72c ------------------------------------------------------------ People who touched revisions under test: Ben Guthro <ben@xxxxxxxxxx> Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> ------------------------------------------------------------ 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 pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-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 test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 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: 25871:a69c8e5c4afc tag: tip user: Jan Beulich <jbeulich@xxxxxxxx> date: Thu Oct 04 10:16:20 2012 +0200 x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Ben Guthro <ben@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 changeset: 25870:648c99c230ff user: Jan Beulich <jbeulich@xxxxxxxx> date: Thu Oct 04 10:15:16 2012 +0200 x86/IRQ: fix valid-old-vector checks in __assign_irq_vector() There are two greater-than-zero checks for the old vector retrieved, which don't work when a negative value got stashed into the respective arch_irq_desc field. The effect of this was that for interrupts that are intended to get their affinity adjusted the first time before the first interrupt occurs, the affinity change would fail, because the original vector assignment would have caused the move_in_progress flag to get set (which causes subsequent re-assignments to fail until it gets cleared, which only happens from the ->ack() actor, i.e. when an interrupt actually occurred). This addresses a problem introduced in c/s 23816:7f357e1ef60a (by changing IRQ_VECTOR_UNASSIGNED from 0 to -1). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25962:41f523f1b5e5 xen-unstable date: Fri Sep 28 07:23:34 UTC 2012 changeset: 25869:051661b76ade user: Jan Beulich <jbeulich@xxxxxxxx> date: Thu Oct 04 10:14:44 2012 +0200 x86/HPET: don't disable interrupt delivery right after setting it up We shouldn't clear HPET_TN_FSB right after we (indirectly, via request_irq()) enabled it for the channels we intend to use for broadcasts. This fixes a regression introduced by c/s 25103:0b0e42dc4f0a. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25961:6a5812129094 xen-unstable date: Fri Sep 28 07:22:14 UTC 2012 changeset: 25868:b4bda6995bc1 user: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> date: Thu Oct 04 10:13:55 2012 +0200 x86: check remote MMIO remap permissions When a domain is mapping pages from a different pg_owner domain, the iomem_access checks are currently only applied to the pg_owner domain, potentially allowing a domain with a more restrictive iomem_access policy to have the pages mapped into its page tables. To catch this, also check the owner of the page tables. The current domain does not need to be checked because the ability to manipulate a domain's page tables implies full access to the target domain, so checking that domain's permission is sufficient. Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> xen-unstable changeset: 25952:8278d7d8fa48 xen-unstable date: Wed Sep 26 09:56:07 UTC 2012 changeset: 25867:b0aed9cadf10 user: Ben Guthro <ben@xxxxxxxxxx> date: Thu Oct 04 10:12:43 2012 +0200 x86/S3: add cache flush on secondary CPUs before going to sleep Secondary CPUs, between doing their final memory writes (particularly updating cpu_initialized) and getting a subsequent INIT, may not write back all modified data. The INIT itself then causes those modifications to be lost, so in the cpu_initialized case the CPU would find itself already initialized, (intentionally) entering an infinite loop instead of actually coming online. Signed-off-by: Ben Guthro <ben@xxxxxxxxxx> Make acpi_dead_idle() call default_dead_idle() rather than duplicating the logic there. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25940:c8d65d91a6f2 xen-unstable date: Tue Sep 25 06:38:14 UTC 2012 changeset: 25866:ffabc1ebd913 user: Jan Beulich <jbeulich@xxxxxxxx> date: Thu Oct 04 10:11:11 2012 +0200 x86: tighten checks in XEN_DOMCTL_memory_mapping handler Properly checking the MFN implies knowing the physical address width supported by the platform, so to obtain this consistently the respective code gets moved out of the MTRR subdir. Btw., the model specific workaround in that code is likely unnecessary - I believe those CPU models don't support 64-bit mode. But I wasn't able to formally verify this, so I preferred to retain that code for now. But domctl code here also was lacking other error checks (as was, looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one. Besides adding the missing checks, printing is also added for the case where revoking access permissions didn't work (as that may have implications for the host operator, e.g. wanting to not pass through affected devices to another guest until the one previously using them did actually die). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25931:149805919569 xen-unstable date: Thu Sep 20 07:21:53 UTC 2012 changeset: 25865:63823a6785fc user: Jan Beulich <jbeulich@xxxxxxxx> date: Thu Oct 04 10:10:23 2012 +0200 x86: properly check XEN_DOMCTL_ioport_mapping arguments for invalid range In particular, the case of "np" being a very large value wasn't handled correctly. The range start checks also were off by one (except that in practice, when "np" is properly range checked, this would still have been caught by the range end checks). Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay? Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25927:3e3959413b2f xen-unstable date: Wed Sep 19 07:27:55 UTC 2012 changeset: 25864:ca3e8190a72c user: Ian Campbell <ian.campbell@xxxxxxxxxx> date: Tue Oct 02 16:02:10 2012 +0100 tools: bump SONAMEs for changes during 4.2 development cycle. We mostly did this as we went along, only a couple of minor number bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2: - Bumped libxl from 1.0.0 -> 1.0.1 - Bumped libxenstore from 3.0.1 -> 3.0.2 Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx> xen-unstable changeset: 25943:0a64f1a3f72c Backport-requested-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |