|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-coverity test] 119806: regressions - ALL FAIL
flight 119806 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/119806/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd64 7 coverity-upload fail REGR. vs. 119558 version targeted for testing: xen 23b40df6f098e3bcb2f105a4909860240976e40f baseline version: xen 24470b99c1671dca531c2cf5747eda2f8892ecbc Last test of basis 119558 2018-02-18 09:47:32 Z 3 days Testing same since 119806 2018-02-21 09:29:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Andrew Cooper <andrew.cooper3@xxxxxxxxx> Dario Faggioli <dfaggioli@xxxxxxxx> Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> jobs: coverity-amd64 fail ------------------------------------------------------------ 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 23b40df6f098e3bcb2f105a4909860240976e40f Author: Julien Grall <julien.grall@xxxxxxx> Date: Fri Feb 16 14:59:56 2018 +0000 xen/arm: vgic: Make sure the number of SPIs is a multiple of 32 The vGIC relies on having a pending_irq available for every IRQs described in the ranks. As each rank describes 32 interrupts, we need to make sure the number of SPIs is a multiple of 32. Reported-by: Jeff Kubascik <Jeff.Kubascik@xxxxxxxxxxxxxxx> Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Cc: Jarvis Roach <Jarvis.Roach@xxxxxxxxxxxxxxx> commit 454ae490487659a51d71adc77aa02892d0725235 Author: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Date: Mon Feb 19 15:07:06 2018 +0200 asm-x86/monitor: Add MONITOR_EVENT_INTERRUPT to common capabilities Signed-off-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> commit 197fbdb501257fdbbe0cfed35e3a99ef5b166107 Author: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Date: Mon Feb 19 11:29:26 2018 +0000 x86/msr: add Raw and Host domain policies Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO msr to the policy during probe_cpuid_faulting(). Host policy may have certain features disabled if Xen decides not to use them. For now, make Host policy equal to Raw policy with cpuid_faulting availability dependent on X86_FEATURE_CPUID_FAULTING. Finally, derive HVM/PV max domain policies from the Host policy. Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit a44f1697968e04fcc6145e3bd51c748b57047240 Author: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Date: Tue Feb 20 10:16:56 2018 +0100 x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap We're noticing a reproducible system boot hang on certain Skylake platforms where the BIOS is configured in legacy boot mode with x2APIC disabled. The system stalls immediately after writing the first SMP initialization sequence into APIC ICR. The cause of the problem is watchdog NMI handler execution - somewhere near the end of NMI handling (after it's already rescheduled the next NMI) it tries to access IO port 0x61 to get the actual NMI reason on CPU0. Unfortunately, this port is emulated by BIOS using SMIs and this emulation for some reason takes more time than we expect during INIT-SIPI-SIPI sequence. As the result, the system is constantly moving between NMI and SMI handler and not making any progress. To avoid this, initialize the watchdog after SMP bootstrap on CPU0 and, additionally, protect the NMI handler by moving IO port access before NMI re-scheduling. The latter should also help in case of post boot CPU onlining. Although we're running watchdog at much lower frequency at this point, it's neveretheless possible we may trigger the issue anyway. Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 682b13c259e531f6848f535032c256ec8fcaca71 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 20 10:10:59 2018 +0100 shim: allow building of just the shim with build-ID-incapable linker The ELF note the shim build inserts causes mkelf32 to choke on the second program header. However, the output of mkelf32 isn't really needed when building inside tools/firmware/ - an attempt to build it is made solely because of a wrong dependency. Further changes to the make logic will be needed to also allow building a shim-enabled "normal" xen with such a linker (as it looks the --notes option will need passing not just when the linker support build ID generation). Also drop a stray variable setting from the x86 Makefile. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 8f9ccfe93570ecae18d9cc224931787d0bca9c66 Author: Dario Faggioli <dfaggioli@xxxxxxxx> Date: Fri Feb 16 19:38:48 2018 +0100 tools: libxenstat: fix format string overflow With gcc 7.3.0, the build fails like this: src/xenstat_linux.c: In function â??getBridgeâ?? src/xenstat_linux.c:78:34: warning: â??%sâ?? directive writing up to 255 bytes into a region of size 241 [-Wformat-overflow=] sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name); ^~ src/xenstat_linux.c:78:5: note: â??sprintfâ?? output between 23 and 278 bytes into a destination of size 256 sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix by making the buffer bigger. Signed-off-by: Dario Faggioli <dfaggioli@xxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit d3b230fc46ee9853064e167f6cb4da8ea0a08112 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Feb 19 14:00:31 2018 +0100 shut down domain when last vCPU goes down I've just had to deal with an early boot crash of Linux which occurred so early that even "earlyprintk=xen" did not produce any useful output. Hence the domain appeared to hang, while in fact it had brought down its only vCPU. By translating this to a shutdown, the situation will be better recognizable. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> commit 0091daa9d911995327ef92c3ce663c3c569c8c6e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon Feb 19 13:59:37 2018 +0100 x86/PV: avoid indirect call/thunk in I/O emulation The stub is within reach from the .text section, so there's no point using an indirect call here. This has the added benefit of there no longer being two sufficiently different approaches, breaking one of which people may not even notice. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxx> (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |