|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 5689: regressions - FAIL
flight 5689 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/5689/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-win 9 guest-localmigrate fail REGR. vs. 5685 test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 5685 test-amd64-xcpkern-i386-xl-win 12 guest-localmigrate/x10 fail REGR. vs. 5685 test-i386-i386-xl-win 11 guest-localmigrate.2 fail REGR. vs. 5685 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-i386-rhel6hvm-intel 8 guest-saverestore 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-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-i386-i386-win 16 leak-check/check fail never pass test-i386-xcpkern-i386-win 16 leak-check/check fail never pass version targeted for testing: xen a0ef80c99264 baseline version: xen 1967c7c290eb ------------------------------------------------------------ People who touched revisions under test: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxxxx> Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Keir Fraser <keir@xxxxxxx> Tim Deegan <Tim.Deegan@xxxxxxxxxx> ------------------------------------------------------------ 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 pass test-i386-i386-xl pass 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 pass 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 pass test-amd64-xcpkern-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-xcpkern-i386-pair pass test-i386-xcpkern-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass 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: 22900:a0ef80c99264 tag: tip user: Keir Fraser <keir@xxxxxxx> date: Thu Feb 10 14:19:54 2011 +0000 x86: suppress HPET broadcast initialization in the presence of ARAT This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0, noticing that all this setup is pointless when ARAT support is there, and knowing that on SLED11's native kernel it has actually caused S3 resume issues. A question would be whether HPET legacy interrupts should be forced off in this case (rather than leaving whatever came from firmware). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 22899:5b18a72d292a user: Keir Fraser <keir@xxxxxxx> date: Thu Feb 10 14:19:23 2011 +0000 x86: tighten conditions under which writing certain MSRs is permitted MSRs that control physical CPU aspects generally are pointless (and possibly dangerous) to be written when the writer isn't sufficiently aware that it's running virtualized. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 22898:332c1f73a594 user: Keir Fraser <keir@xxxxxxx> date: Thu Feb 10 14:14:24 2011 +0000 ix86: re-do permanent disabling of x2apic Move logic into check_x2apic_preenabled() (to make sure generic_apic_probe() doesn't see genapic already set). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 22897:21df67ee7040 user: Tim Deegan <Tim.Deegan@xxxxxxxxxx> date: Thu Feb 10 11:27:52 2011 +0000 x86/mm: make log-dirty code do all its allocations outside the lock to avoid taking the shadow/EPT lock with the lgd lock held. Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx> changeset: 22896:0df1b42910b1 user: Tim Deegan <Tim.Deegan@xxxxxxxxxx> date: Thu Feb 10 11:27:51 2011 +0000 x86/mm: shuffle log-dirty code so only one path allocates memory Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx> changeset: 22895:19b2424be183 user: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> date: Thu Feb 10 09:02:50 2011 +0000 Cpupools: vcpu affinity handling If a vcpu is pinned to multiple physical cpus, the pinning is not removed if all those physical cpus are removed from the cpupool. When disabling the scheduler on a cpu, the affinity mask must be checked against the cpumask of the cpupool. Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> changeset: 22894:1967c7c290eb user: Tim Deegan <Tim.Deegan@xxxxxxxxxx> date: Wed Feb 09 12:03:09 2011 +0000 x86/mm/shadow: fix unlocking on error path in p2m allocator One unlock path wasn't gated to match the lock. Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx> ======================================== commit ad7d28519de7cdc604efefac5c22fe9f88040586 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue Feb 1 17:32:38 2011 +0000 vnc, xen: write vnc address and password to xenstore The xend protocol as actually implemented is: * xend writes: /vm/UUID/vncpasswd = "PASS" (n0,rDOMID) /local/domain/0/backend/vfb/DOMID/0/vncunused = "0" (n0,rDOMID) /local/domain/0/backend/vfb/DOMID/0/vnc = "1" (n0,rDOMID) /local/domain/0/backend/vfb/DOMID/0/vnclisten = "ADDR" (n0,rDOMID) /local/domain/0/backend/vfb/DOMID/0/vncdisplay = "PORT" (n0,rDOMID) /local/domain/0/backend/vfb/DOMID/0/vncpasswd = "PASS" (n0,rDOMID) * qemu reads /vm/UUID/vncpasswd and overwrites it with "\0" * qemu writes /local/domain/DOMID/console/vnc-port = "PORT" (n0,rDOMID) * xm vncviewer reads entries from backend/vfb, as well as console/vnc-port. Much of this is insane. xl quite properly does not create anything in backend/vfb for an HVM domain with no vfb. But xl vncviewer needs to know the port number and the address and the password. So, for now, have qemu write these nodes too: /local/domain/DOMID/console/vnc-listen = "ADDR" (n0,rDOMID) /local/domain/DOMID/console/vnc-pass = "PASS" (n0,rDOMID) This corresponds to the protocol actually currently implemented in libxl. We will revisit this after the 4.1 release and invent a non-insane protocol. Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |