|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 21865: regressions - FAIL
flight 21865 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/21865/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win7-amd64 10 guest-saverestore.2 fail REGR. vs. 21435 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass version targeted for testing: xen a002c8491b8dcc81633f1f9b0177c2b44593ba89 baseline version: xen 96b59ae2dcaa639a4f58c68f122f8ba8738009dc ------------------------------------------------------------ People who touched revisions under test: David Vrabel <david.vrabel@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Keir Fraser <keir@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass 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-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-qemut-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-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-i386-xend-qemut-winxpsp3 fail test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-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. ------------------------------------------------------------ commit a002c8491b8dcc81633f1f9b0177c2b44593ba89 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 11 16:20:51 2013 +0100 x86: print relevant (tail) part of filename for warnings and crashes In particular when the origin construct is in a header file (and hence the file name is an absolute path instead of just the file name portion) the information can otherwise become rather useless when the build tree isn't sitting relatively close to the file system root. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: f72cb6bbc10348f4f7671428e5db509731e9e6a5 master date: 2013-10-17 11:35:26 +0200 commit 6dd29df224cdf4c14824b32b6a48747811aa456a Author: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Date: Mon Nov 11 16:20:14 2013 +0100 credit: unpause parked vcpu before destroying it A capped out vcpu must be unpaused in case of moving it to another cpupool, otherwise it will be paused forever. Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> master commit: d38a668b6ef8c84d1d3fda9947ffb0056d01fe3a master date: 2013-10-16 12:26:48 +0200 commit da128be2c55e3f60dd025ff7480396bd74a5a12d Author: David Vrabel <david.vrabel@xxxxxxxxxx> Date: Mon Nov 11 16:19:36 2013 +0100 sched: fix race between sched_move_domain() and vcpu_wake() sched_move_domain() changes v->processor for all the domain's VCPUs. If another domain, softirq etc. triggers a simultaneous call to vcpu_wake() (e.g., by setting an event channel as pending), then vcpu_wake() may lock one schedule lock and try to unlock another. vcpu_schedule_lock() attempts to handle this but only does so for the window between reading the schedule_lock from the per-CPU data and the spin_lock() call. This does not help with sched_move_domain() changing v->processor between the calls to vcpu_schedule_lock() and vcpu_schedule_unlock(). Fix the race by taking the schedule_lock for v->processor in sched_move_domain(). Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx> Acked-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> Use vcpu_schedule_lock_irq() (which now returns the lock) to properly retry the locking should the to be used lock have changed in the course of acquiring it (issue pointed out by George Dunlap). Add a comment explaining the state after the v->processor adjustment. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: ef55257bc81204e34691f1c2aa9e01f2d0768bdd master date: 2013-10-14 08:58:31 +0200 commit 836ac327ac02f726a655444588df51f51484aebe Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 11 16:18:39 2013 +0100 fix locking in cpu_disable_scheduler() So commit eedd6039 ("scheduler: adjust internal locking interface") uncovered - by now using proper spin lock constructs - a bug after all: When bringing down a CPU, cpu_disable_scheduler() gets called with interrupts disabled, and hence the use of vcpu_schedule_lock_irq() was never really correct (i.e. the caller ended up with interrupts enabled despite having disabled them explicitly). Fixing this however surfaced another problem: The call path vcpu_migrate() -> evtchn_move_pirqs() wants to acquire the event lock, which however is a non-IRQ-safe once, and hence check_lock() doesn't like this lock to be acquired when interrupts are already off. As we're in stop-machine context here, getting things wrong wrt interrupt state management during lock acquire/release is out of question though, so the simple solution to this appears to be to just suppress spin lock debugging for the period of time while the stop machine callback gets run. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 41a0cc9e26160a89245c9ba3233e3f70bf9cd4b4 master date: 2013-10-29 09:57:14 +0100 commit fbf12a33fe7cb54feb2d15cd970e910c92103e6c Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 11 16:17:20 2013 +0100 scheduler: adjust internal locking interface Make the locking functions return the lock pointers, so they can be passed to the unlocking functions (which in turn can check that the lock is still actually providing the intended protection, i.e. the parameters determining which lock is the right one didn't change). Further use proper spin lock primitives rather than open coded local_irq_...() constructs, so that interrupts can be re-enabled as appropriate while spinning. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: eedd60391610629b4e8a2e8278b857ff884f750d master date: 2013-10-14 08:57:56 +0200 commit d86a985a273662f3275ee60585d7507d457802a1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Nov 11 09:17:32 2013 +0100 nested VMX: VMLANUCH/VMRESUME emulation must check permission first thing Otherwise uninitialized data may be used, leading to crashes. This is CVE-2013-4551 / XSA-75. Reported-and-tested-by: Jeff Zimmerman <Jeff_Zimmerman@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-and-tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: 4e87bc5b03e05123ba5c888f77969140c8ebd1bf master date: 2013-11-11 09:15:04 +0100 (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 |