|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 187157: regressions - FAIL
flight 187157 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/187157/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-build fail REGR. vs. 187127 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass version targeted for testing: xen bec25f11d5180d407cf04d2de2525fa6f876bde1 baseline version: xen ded5474718a84366dac80aae039a693b66fa7e2e Last test of basis 187127 2024-08-02 22:02:05 Z 2 days Failing since 187154 2024-08-05 09:02:05 Z 0 days 2 attempts Testing same since 187157 2024-08-05 13:12:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jan Beulich <jbeulich@xxxxxxxx> Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ 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 bec25f11d5180d407cf04d2de2525fa6f876bde1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Aug 5 12:55:37 2024 +0200 Revert "x86/dom0: delay setting SMAP after dom0 build is done" This reverts commit ac6b9309694de9b2b5163886656282f6ada71565. The change crashes Xen on boot on SMAP-capable systems. commit ac6b9309694de9b2b5163886656282f6ada71565 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Mon Aug 5 10:18:05 2024 +0200 x86/dom0: delay setting SMAP after dom0 build is done Delay setting X86_CR4_SMAP on the BSP until the domain building is done, so that there's no need to disable SMAP. Note however that SMAP is enabled for the APs on bringup, as domain builder code strictly run on the BSP. Delaying the setting for the APs would mean having to do a callfunc IPI later in order to set it on all the APs. The fixes tag is to account for the wrong usage of cpu_has_smap in create_dom0(), it should instead have used boot_cpu_has(X86_FEATURE_XEN_SMAP). While there also make cr4_pv32_mask __ro_after_init. Fixes: 493ab190e5b1 ('xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself') Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit d81dd31303513a1626973778d557a6493d86511a Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Mon Aug 5 10:16:54 2024 +0200 x86/shutdown: change default reboot method preference The current logic to chose the preferred reboot method is based on the mode Xen has been booted into, so if the box is booted from UEFI, the preferred reboot method will be to use the ResetSystem() run time service call. However, that method seems to be widely untested, and quite often leads to a result similar to: Hardware Dom0 shutdown: rebooting machine ----[ Xen-4.18-unstable x86_64 debug=y Tainted: C ]---- CPU: 0 RIP: e008:[<0000000000000017>] 0000000000000017 RFLAGS: 0000000000010202 CONTEXT: hypervisor [...] Xen call trace: [<0000000000000017>] R 0000000000000017 [<ffff83207eff7b50>] S ffff83207eff7b50 [<ffff82d0403525aa>] F machine_restart+0x1da/0x261 [<ffff82d04035263c>] F apic_wait_icr_idle+0/0x37 [<ffff82d040233689>] F smp_call_function_interrupt+0xc7/0xcb [<ffff82d040352f05>] F call_function_interrupt+0x20/0x34 [<ffff82d04033b0d5>] F do_IRQ+0x150/0x6f3 [<ffff82d0402018c2>] F common_interrupt+0x132/0x140 [<ffff82d040283d33>] F arch/x86/acpi/cpu_idle.c#acpi_idle_do_entry+0x113/0x129 [<ffff82d04028436c>] F arch/x86/acpi/cpu_idle.c#acpi_processor_idle+0x3eb/0x5f7 [<ffff82d04032a549>] F arch/x86/domain.c#idle_loop+0xec/0xee **************************************** Panic on CPU 0: FATAL TRAP: vector = 6 (invalid opcode) **************************************** Which in most cases does lead to a reboot, however that's unreliable. Change the default reboot preference to prefer ACPI over UEFI if available and not in reduced hardware mode. This is in line to what Linux does, so it's unlikely to cause issues on current and future hardware, since there's a much higher chance of vendors testing hardware with Linux rather than Xen. Add a special case for one Acer model that does require being rebooted using ResetSystem(). See Linux commit 0082517fa4bce for rationale. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |