|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 138485: regressions - trouble: blocked/fail
flight 138485 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/138485/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 138424 build-arm64-xsm 6 xen-build fail REGR. vs. 138424 build-armhf 6 xen-build fail REGR. vs. 138424 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0 baseline version: xen 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d Last test of basis 138424 2019-06-24 11:00:52 Z 1 days Failing since 138482 2019-06-25 15:00:47 Z 0 days 2 attempts Testing same since 138485 2019-06-25 16:00:57 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-libvirt blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 1bef4b1efd40b4c8c9e7afcd0155042a47896cb0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jun 25 17:34:53 2019 +0200 drop __get_cpu_var() and __get_cpu_ptr() this_cpu{,_ptr}() are shorter, and have previously been marked as preferred in Xen anyway. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 62b8949e9ddefa3191688ccc56e69aa6331b0da1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jun 25 17:34:11 2019 +0200 x86: replace remaining uses of __get_cpu_var() this_cpu() is shorter, and when there are multiple uses in a function per_cpu() it's also more efficient. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 19b2006a8950eaf11606a6fc3df666f2982321ad Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jun 25 17:33:40 2019 +0200 x86/mcheck: replace remaining uses of __get_cpu_var() this_cpu() is shorter, and when there are multiple uses in a function per_cpu() it's also more efficient. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 560cf418c8455cd8d79ad353f6f9193a2e2554e4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jun 25 17:32:37 2019 +0200 x86/mcheck: allow varying bank counts per CPU Up to now we've been assuming that all CPUs would have the same number of reporting banks. However, on upcoming AMD CPUs this isn't the case, and one can observe (XEN) mce.c:666: Different bank number on cpu <N> indicating that Machine Check support would not be enabled on the affected CPUs. Convert the count variable to a per-CPU one, and adjust code where needed to cope with the values not being the same. In particular the mcabanks_alloc() invocations during AP bringup need to now allocate maximum-size bitmaps, because the truly needed size can't be known until we actually execute on that CPU, yet mcheck_init() gets called too early to do any allocations itself. Take the liberty and also - make mca_cap_init() static, - replace several __get_cpu_var() uses when a local variable suitable for use with per_cpu() appears, - correct which CPU's cpu_data[] entry x86_mc_msrinject_verify() uses, - replace a BUG() by panic(). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit b41666f2c17f01c437c870389ab713ee62ae3526 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Jun 25 15:39:44 2019 +0200 config: don't hardcode toolchain binaries Currently the names of the build toolchain binaries are hardcoded in StdGNU.mk, and the values from the environment are ignored. Switch StdGNU.mk to use '?=' instead of '=', so that values from the environment are used if present, else default to the values provided by the config file. This change fixes the gitlab CI loop, that was relying on passing custom values in the environment variables for the compiler and the linker. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |