|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 19843: regressions - trouble: broken/fail/pass
flight 19843 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/19843/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 19832 test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 19832 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 3 host-install(3) broken never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start 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-win7-amd64 13 guest-stop 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-qemuu-winxpsp3 13 guest-stop fail never pass version targeted for testing: xen 3e1ecba84056a6a8f545fae7a72702097cede4fa baseline version: xen 945b86cb98713cd6039de14597d1bd11bae58314 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Keir Fraser <keir@xxxxxxx> Matt Wilson <msw@xxxxxxxxxx> ------------------------------------------------------------ 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 broken 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 3e1ecba84056a6a8f545fae7a72702097cede4fa Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Sep 27 11:59:54 2013 +0200 x86/HVM: refuse doing string operations in certain situations We shouldn't do any acceleration for - "rep movs" when either side is passed through MMIO or when both sides are handled by qemu - "rep ins" and "rep outs" when the memory operand is any kind of MMIO Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 14fcce2fa883405bab26b60821a6cc5f2c770833 master date: 2013-09-23 09:55:14 +0200 commit 6db5da83ecaebfb1a651178334a10e7d1fa13dcc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Sep 27 11:59:14 2013 +0200 x86/HVM: linear address must be canonical for the whole accessed range ... rather than just for the first byte. While at it, also - make the real mode case at least dpo a wrap around check - drop the mis-named "gpf" label (we're not generating faults here) and use in-place returns instead Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 7f12732670b31b2fea899a4160d455574658474f master date: 2013-09-23 09:53:55 +0200 commit fb272e48312cf1ba377aa1415461a271a3e06986 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Fri Sep 27 11:57:59 2013 +0200 sched_credit: filter node-affinity mask against online cpus in _csched_cpu_pick(), as not doing so may result in the domain's node-affinity mask (as retrieved by csched_balance_cpumask() ) and online mask (as retrieved by cpupool_scheduler_cpumask() ) having an empty intersection. Therefore, when attempting a node-affinity load balancing step and running this: ... /* Pick an online CPU from the proper affinity mask */ csched_balance_cpumask(vc, balance_step, &cpus); cpumask_and(&cpus, &cpus, online); ... we end up with an empty cpumask (in cpus). At this point, in the following code: .... /* If present, prefer vc's current processor */ cpu = cpumask_test_cpu(vc->processor, &cpus) ? vc->processor : cpumask_cycle(vc->processor, &cpus); .... an ASSERT (from inside cpumask_cycle() ) triggers like this: (XEN) Xen call trace: (XEN) [<ffff82d08011b124>] _csched_cpu_pick+0x1d2/0x652 (XEN) [<ffff82d08011b5b2>] csched_cpu_pick+0xe/0x10 (XEN) [<ffff82d0801232de>] vcpu_migrate+0x167/0x31e (XEN) [<ffff82d0801238cc>] cpu_disable_scheduler+0x1c8/0x287 (XEN) [<ffff82d080101b3f>] cpupool_unassign_cpu_helper+0x20/0xb4 (XEN) [<ffff82d08010544f>] continue_hypercall_tasklet_handler+0x4a/0xb1 (XEN) [<ffff82d080127793>] do_tasklet_work+0x78/0xab (XEN) [<ffff82d080127a70>] do_tasklet+0x5f/0x8b (XEN) [<ffff82d080158985>] idle_loop+0x57/0x5e (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) Assertion 'cpu < nr_cpu_ids' failed at /home/dario/Sources/xen/xen/xen.git/xen/include/xe:16481 It is for example sufficient to have a domain with node-affinity to NUMA node 1 running, and issueing a `xl cpupool-numa-split' would make the above happen. That is because, by default, all the existing domains remain assigned to the first cpupool, and it now (after the cpupool-numa-split) only includes NUMA node 0. This change prevents that by generalizing the function used for figuring out whether a node-affinity load balancing step is legit or not. This way we can, in _csched_cpu_pick(), figure out early enough that the mask would end up empty, skip the step all together and avoid the splat. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> master commit: 5e5a44b6c942d6ea47f15d6f1ed02b03e0d69445 master date: 2013-09-20 11:37:28 +0200 commit 8294ffb817a795f93e241192c59e34c9da281b8b Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 27 11:54:42 2013 +0200 watchdog/crash: Always disable watchdog in console_force_unlock() Depending on the state of the conring and serial_tx_buffer, console_force_unlock() can be a long running operation, usually because of serial_start_sync() XenServer testing has found a reliable case where console_force_unlock() on one PCPU takes long enough for another PCPU to timeout due to the watchdog (such as waiting for a tlb flush callin). The watchdog timeout causes the second PCPU to repeat the console_force_unlock(), at which point the first PCPU typically fails an assertion in spin_unlock_irqrestore(&port->tx_lock) (because the tx_lock has been unlocked behind itself). console_force_unlock() is only on emergency paths, so one way or another the host is going down. Disable the watchdog before forcing the console lock to help prevent having pcpus completing with each other to bring the host down. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 7b9fa702ca323164d6b49e8b639a57f880454a8c master date: 2013-08-13 14:31:01 +0200 commit 0a2210f134fda565c7c3256215694aa2b8a2cebc Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Sep 27 11:53:26 2013 +0200 xen/conring: Write to console ring even if console lock is busted console_lock_busted gets set when an NMI/MCE/Double Fault handler decides to bring Xen down in an emergency. conring_puts() cannot block and does not have problematic interactions with the console_lock. Therefore, choosing to not put the string into the console ring simply means that the kexec environment cant find any panic() message caused by an IST interrupt, which is unhelpful for debugging purposes. In the case that two pcpus fight with console_force_unlock(), having slightly garbled strings in the console ring is far more useful than having nothing at all. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Matt Wilson <msw@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> master commit: 66450c1d1ab3c4480bbba949113b95d1ab6a943a master date: 2013-08-06 17:45:00 +0200 (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 |