[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-unstable test] 29577: regressions - FAIL



flight 29577 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/29577/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore.2 fail REGR. vs. 
29537

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass
 test-amd64-i386-libvirt       9 guest-start                  fail   never pass
 test-armhf-armhf-libvirt      9 guest-start                  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop                fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass

version targeted for testing:
 xen                  8b24b07eef3ba13ce48d800f28c1c28de5a2b4a7
baseline version:
 xen                  a1ac4cf52e38386bac7ac3440c7da0099662ca5c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  Don Slutz <dslutz@xxxxxxxxxxx>
  Feng Wu <feng.wu@xxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
  Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 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-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumpuserxen-amd64                           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-i386-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-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             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-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      fail    
 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-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-i386-xl-qemut-winxpsp3                            fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xl-qemuu-winxpsp3                            fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-amd64-i386-xl-winxpsp3                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.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 8b24b07eef3ba13ce48d800f28c1c28de5a2b4a7
Author: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
Date:   Fri Aug 1 16:48:30 2014 +0200

    x86, amd_ucode: safeguard against #GP
    
    When HW tries to load a corrupted patch, it generates #GP
    and depending on 'noreboot' parameter on grub, the system
    is either stuck in a reboot loop or is hung. Use wrmsr_safe
    instead of wrmsrl so that we fail to load microcode gracefully.
    
    Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 6784dd6fdc43914e9bf5b080e12c7877d000dffa
Author: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
Date:   Fri Aug 1 16:47:48 2014 +0200

    x86, amd_ucode: fix coverity issues found in cpu_request_microcode()
    
    This patch fixes issues reported by coverity.
     - CID 1229147: dead code
     - CID 1229148: possible resource leak of mc_amd due to goto out statements.
    
    Coverity-IDs: 1229147, 1229148
    Reported-by: Andrew Cooper<andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
    Reviewed-by: Andrew Cooper<andrew.cooper3@xxxxxxxxxx>

commit 400b3bd6426f3334e47f16d55fd42f438d7fe6fa
Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
Date:   Fri Aug 1 16:46:40 2014 +0200

    evtchn: make EVTCHNOP_reset suitable for kexec
    
    It would be nice to allow guests to close all event channels in
    ABI-agnostic way in case of kexec/kdump. EVTCHNOP_reset looks suitable
    for this purpose. However control blocks for vcpus and event array need
    cleanup when FIFO ABI is being used.
    
    With this change a guest can simply do EVTCHNOP_reset before kexec in
    both 2-level and FIFO cases. It is also important to perform store/console
    channel remapping after such call.
    
    The issue can also be solved by introducing a new EVTCHNOP operation but
    it seems that EVTCHNOP_reset can be reused.
    
    [The idea was suggested by Ian Campbell, Andrew Cooper, and David Vrabel]
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>

commit 340f8cb83013dc80ebd29ed5b743040a5a45c146
Author: Feng Wu <feng.wu@xxxxxxxxx>
Date:   Fri Aug 1 16:40:39 2014 +0200

    x86/hvm: always do SMAP check when updating secondary system time for guest
    
    In this patch, we always do the SMAP check when updating secondary
    system time for the guest when SMAP is enabled by it.
    
    Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 31ae587e6f0181bf1f7d196fe1b49357c8922e60
Author: Feng Wu <feng.wu@xxxxxxxxx>
Date:   Fri Aug 1 16:39:17 2014 +0200

    x86/hvm: always do SMAP check when updating runstate_guest(v)
    
    In the current implementation, we honor the guest's CPL and AC
    to determain whether do the SMAP check or not for runstate_guest(v).
    However, this doesn't work. The VMCS feild is invalid when we try
    to get geust's SS by hvm_get_segment_register(), since the
    right VMCS has not beed loaded for the current VCPU.
    
    In this patch, we always do the SMAP check when updating
    runstate_guest(v) for the guest when SMAP is enabled by it.
    
    Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
    Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>

commit d91b0f9b58219724717db503f46ff2f731aa4c59
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Aug 1 16:32:39 2014 +0200

    x86/cpu: drop the num_siblings check against nr_cpu_ids
    
    The printk() is missing a newline which resulted in console corruption.
    
    However, nr_cpu_ids can be legitimately lower than valid num_sibling values
    given certain compile or boot time configuration.
    
    Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit e9425f05b90811458a08355a55a0b0d608c440cf
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Aug 1 16:29:27 2014 +0200

    x86/ACPI: allow CMOS RTC use even when ACPI says there is none
    
    HP is setting the ACPI_FADT_NO_CMOS_RTC flag on newer systems,
    regardless of whether they're being booted from UEFI. Add a command
    line option to allow probing for a working RTC in that case.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit fb33b2bd7fda7b183a6bf07995c0ff476b676414
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Aug 1 16:28:48 2014 +0200

    docs: make .txt files over-writable when building from r/o sources
    
    Otherwise an incremental build will fail to overwrite the destination
    files.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 705fad1227a3313f05e0f64da46d19a5c52dacde
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 29 18:07:09 2014 +0200

    libxl: automatic NUMA placement affects soft affinity
    
    vCPU soft affinity and NUMA-aware scheduling does not have
    to be related. However, soft affinity is how NUMA-aware
    scheduling is actually implemented, and therefore, by default,
    the results of automatic NUMA placement (at VM creation time)
    are also used to set the soft affinity of all the vCPUs of
    the domain.
    
    Of course, this only happens if automatic NUMA placement is
    enabled and actually takes place (for instance, if the user
    does not specify any hard and soft affiniy in the xl config
    file).
    
    This also takes care of the vice-versa, i.e., don't trigger
    automatic placement if the config file specifies either an
    hard (the check for which was already there) or a soft (the
    check for which is introduced by this commit) affinity.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 3d00662816fe74678c5b233c59e40dca604ca2bd
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 29 18:06:52 2014 +0200

    libxl/xl: make it possible to specify soft-affinity in domain config file
    
    To do so, we add the vcpu_soft_affinity array to build_info, and
    treat it much like vcpu_hard_affinity. The new config option is
    called "cpus_soft".
    
    Note that the vcpu_hard_affinity array, introduced in a previous
    patch, and the vcpu_soft_affinity array, introduced here, share
    the same LIBXL_HAVE_xxx macro, in libxl.h. That is called
    LIBXL_HAVE_BUILDINFO_VCPU_AFFINITY_ARRAYS, and was introduced
    together with vcpu_hard_affinity, but only inside a comment.
    In this change, we uncomment, and hence properly define it.
    
    In order to avoid having to issue separate calls to
    libxl_set_vcpuaffinity() (one for hard affinity and one for soft
    affinity) in libxl__build_pre(), in case the caller uses
    b_info->cpumap (for the former) and b_info->vcpu_soft_affinity (for
    the latter), we also set (again!) a new default for b_info->cpumap.
    This allows, from this change on, to always and only deal with
    b_info->vcpu_hard_affinity all around libxl internals.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 14ea07848b8b0f00ea311ee5413932129b6f6c72
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 29 18:06:42 2014 +0200

    xl: move the vcpu affinity parsing in a function
    
    so that such parsing code can be used for both hard and soft
    affinity, the support for which is introduced in the next
    change.
    
    This is pure code motion, no functional change intended.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit af589e1a9c77c52be5da84c6eabc92a2bb0e72d2
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 29 18:06:28 2014 +0200

    xl: move away from the use of cpumap for hard affinity
    
    and start using the vcpu_hard_affinity array instead. This is done
    as when, in a subsequent patch ("libxl/xl: make it possible to
    specify soft-affinity in domain config file") we will become able
    to deal with soft affinity, code can be shared.
    
    This change also enables more advanced VCPU to PCPU (hard, for now)
    affinity specification, in case a list is used, like:
    
          cpus = ["3-4", "2-6,^4"]
    
    What it means is that VCPU 0 must be pinned to PCPU 3,4 and VCPU 1
    to PCPUs 2,3,5,6 (before this change, cpus=[xx, yy] only supported
    single values). Of course, the old (e.g., cpus=[2, 3]) syntax
    continues to work.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 7e474ba61c2fa6babf77466bbf4ce873733a9670
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 29 18:06:17 2014 +0200

    xl: enable getting and setting soft affinity
    
    Getting happens via `xl vcpu-list', which now looks like this:
    
     # xl vcpu-list -s
     Name       ID VCPU CPU State Time(s) Affinity (Hard / Soft)
     Domain-0   0     0  11  -b-     5.4  8-15 / all
     Domain-0   0     1  11  -b-     1.0  8-15 / all
     Domain-0   0    14  13  -b-     1.4  8-15 / all
     Domain-0   0    15   8  -b-     1.6  8-15 / all
     vm-test    3     0   4  -b-     2.5  0-12 / 0-7
     vm-test    3     1   0  -b-     3.2  0-12 / 0-7
    
    Setting happens by specifying two pCPU masks to the `xl vcpu-pin'
    command, the first one will be hard affinity, the second soft
    affinity. If only one mask is specified, it is only hard affinity
    that is affected. To change only soft affinity, '-' can be used
    as the hard affinity mask parameter, and it will be left alone.
    
    xl manual page is updated accordingly.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 9ef51438e5410650c0525274dcfc7e1a503b6833
Author: Don Slutz <dslutz@xxxxxxxxxxx>
Date:   Mon Jul 28 12:06:02 2014 -0400

    xenbaked.c: Fix return handling for case of mmap failure
    
    mmap() returns MAP_FAILED not NULL.
    
    Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 8a14ca08f2aa5e52ffd8b42792ae1f3a708339ee
Author: Don Slutz <dslutz@xxxxxxxxxxx>
Date:   Mon Jul 28 12:06:01 2014 -0400

    libxl_internal.c: Fix return handling for case of mmap failure
    
    mmap() returns MAP_FAILED not NULL.
    
    Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

commit 822b956ef7d5ccab86133d0cc8d49d87103adf3e
Author: Don Slutz <dslutz@xxxxxxxxxxx>
Date:   Mon Jul 28 12:06:00 2014 -0400

    loadpolicy.c: Fix return handling for case of mmap failure
    
    mmap() returns MAP_FAILED not NULL.
    
    Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.