|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 10631: regressions - FAIL
flight 10631 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/10631/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 10630 Tests which did not succeed, but are not blocking: 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-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-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop 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-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass version targeted for testing: xen efaa28639a71 baseline version: xen 50117a4d1a2c ------------------------------------------------------------ People who touched revisions under test: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Gang Wei <gang.wei@xxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Haitao Shan <haitao.shan@xxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Joseph Cihula <joseph.cihula@xxxxxxxxx> Keir Fraser <keir@xxxxxxx> Shan Haitao <maillists.shan@xxxxxxxxx> Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx> ------------------------------------------------------------ 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-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 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-xl-sedf-pin pass test-amd64-amd64-pv pass 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-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: 24452:efaa28639a71 tag: tip user: Dario Faggioli <dario.faggioli@xxxxxxxxxx> date: Wed Jan 04 16:12:44 2012 +0000 Rework locking for sched_adjust. The main idea is to move (as much as possible) locking logic from generic code to the various pluggable schedulers. While at it, the following is also accomplished: - pausing all the non-current VCPUs of a domain while changing its scheduling parameters is not effective in avoiding races and it is prone to deadlock, so that is removed. - sedf needs a global lock for preventing races while adjusting domains' scheduling parameters (as it is for credit and credit2), so that is added. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> changeset: 24451:d82be53b3ea1 user: Dario Faggioli <dario.faggioli@xxxxxxxxxx> date: Wed Jan 04 16:11:46 2012 +0000 All domains (including dom0) should be best effort on creation In the sedf scheduler, while trying to guarantee to dom0 the proper amount of CPU time for being able to do its job, we end up allocating 75% CPU-share to each and every of its VCPUs. This, combined with the fact that such a scheduler has no load balancing logic at all (and thus *all* dom0's VCPUs just rise and stay on physical CPU #0), means that for example on a 12-cores system we're trying to exploit 75x12=3D900% of what we have on a PCPU, which is definitely too much! Moreover, even if a cleverer mechanism for distributing VCPUs among the available PCPUs (if not a proper load balancer) will be put in place some day, it will still be difficult to decide how much guaranteed CPU bandwidth each of the dom0's VCPUs should be provided with, without posing the system at risk of livelock or starvation, even during boot time. Therefore, since sedf is capable of some form of best-effort scheduling, the best thing we can do is ask for this behaviour for dom0, as it is for all other domains, right upon creation. It will then be the sysadmin's job to modify dom0's scheduling parameters to better fit his particular needs, maybe after spreading the load a bit by pinning VCPUs on PCPUs, or using cpupools, etc. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> changeset: 24450:50117a4d1a2c user: Gang Wei <gang.wei@xxxxxxxxx> date: Mon Jan 02 12:43:07 2012 +0000 x86/tboot: fix some coding style issues in tboot.c Signed-off-by: Gang Wei <gang.wei@xxxxxxxxx> Acked-by: Joseph Cihula <joseph.cihula@xxxxxxxxx> Committed-by: Keir Fraser <keir@xxxxxxx> ======================================== commit 56d7747a3cf811910c4cf865e1ebcb8b82502005 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Thu Dec 22 14:46:31 2011 +0000 qemu: clean up MSI-X table handling This patch does cleaning up of QEMU MSI handling. The fixes are: 1. Changes made to MSI-X table mapping handling to eliminate the small windows in which guest could have access to physical MSI-X table. 2. MSI-X table is mapped as read-only to QEMU, as masking of MSI-X is already in Xen now. 3. For registers that coexists inside the MSI-X table (this could be only PBA I think), value read from physical page would be returned. Signed-off-by: Shan Haitao <maillists.shan@xxxxxxxxx> Consolidated duplicate code into _pt_iomem_helper(). Fixed formatting. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Haitao Shan <haitao.shan@xxxxxxxxx> Acked-by: Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |