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

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

flight 12250 xen-unstable real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 12249
 build-i386                    4 xen-build                 fail REGR. vs. 12249

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install          fail never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install        fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  46bf3ab42baf
baseline version:
 xen                  1b68427875f7

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>

 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 

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

Test harness code can be found at

Not pushing.

changeset:   25069:46bf3ab42baf
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Fri Mar 16 11:35:06 2012 +0100
    unmodified drivers: use upstream sync_bitops if available
    The forward ported xenlinux sources in openSuSE 12.2 were switched from
    the old synch_bitops to the sync_bitops since kernel version 3.3. Add
    compat macros to use either old or new helpers depending on used kernel
    source version.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
changeset:   25068:e4460795ee66
user:        Olaf Hering <olaf@xxxxxxxxx>
date:        Fri Mar 16 11:34:41 2012 +0100
    unmodified drivers: add pfn_is_ram helper for kdump
    Register pfn_is_ram helper speed up reading /proc/vmcore in the kdump
    kernel. It is compiled only if the kernel source is recent enough to
    have the pfn_is_ram helper (v3.0-rc1, commit
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Committed-by: Jan Beulich <jbeulich@xxxxxxxx>
changeset:   25067:05768bd498f2
user:        Olaf Hering <olaf@xxxxxxxxx>
date:        Fri Mar 16 11:34:14 2012 +0100
    unmodified drivers: hide xen_cpuid_base() in version 2.6.38+
    Allow compilation of PVonHVM drivers with forward-ported xenlinux
    sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
    in the xen tree leads to a compilation error.  The current state leads
    to a compile error:
 error: redefinition of 'xen_cpuid_base'
    /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43: error: 
previous definition of 'xen_cpuid_base' was here
    The reason is that the kernel sources are searched before the xen
    sources for asm/hypervisor.h:
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Committed-by: Jan Beulich <jbeulich@xxxxxxxx>
changeset:   25066:be9aaa70e513
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Fri Mar 16 11:33:22 2012 +0100
    list maintainers of unmodified_drivers/linux-2.6/
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
changeset:   25065:377c075ec0ec
user:        Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
date:        Fri Mar 16 10:30:12 2012 +0000
    KEXEC: Allocate crash structures in low memory
    On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
    as the CPU crash notes will go into the xenheap, which tends to be in
    upper memory.  This causes problems on machines with more than 64GB
    (or 4GB if no PAE support) of ram as the crashkernel physically cant
    access the crash notes.
    The solution is to force Xen to allocate certain structures in lower
    memory.  This is achieved by introducing two new command line
    parameters; low_crashinfo and crashinfo_maxaddr.  Because of the
    potential impact on 32bit PV guests, and that this problem does not
    exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
    the codebase's previous behavior, requiring the user to explicitly
    add extra command line parameters to change the behavior.
    This patch consists of 3 logically distinct but closely related
     1) Add the two new command line parameters.
     2) Change crash note allocation to use lower memory when instructed.
     3) Change the conring buffer to use lower memory when instructed.
    There result is that the crash notes and console ring will be placed
    in lower memory so useful information can be recovered in the case of
    a crash.
    Changes since v1:
     -  Patch xen-command-line.markdown to document new options
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Committed-by: Keir Fraser <keir@xxxxxxx>
changeset:   25064:0e3ed266b3bb
user:        Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
date:        Fri Mar 16 10:29:20 2012 +0000
    KEXEC: Allocate crash notes on boot
    Currently, the buffers for crash notes are allocated per CPU when a
    KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
    question.  This has certain problems including not being able to
    allocate the crash buffers if the host is out of memory when crashing.
    In addition, my forthcoming code to support 32bit kdump kernels on
    64bit Xen on large (>64GB) boxes will require some guarentees as to
    where the crash note buffers are actually allocated in physical
    memory.  This is far easier to sort out at boot time, rather than
    after dom0 has been booted and potentially using the physical memory
    Therefore, allocate the crash note buffers at boot time.
    Changes since v6:
     *  Tweak kexec_init() to use xzmalloc_array(), and to defer
     registering the
        crashdump keyhandler until the crash notes have been successfully
    Changes since v5:
     *  Introduce sizeof_cpu_notes to move calculation of note size into a
        separate location.
     *  Tweak sizeof_note() to return size_t rather than int, as it is a
        function based upon sizeof().
    Changes since v4:
     *  Replace the current cpu crash note scheme of using void pointers
        and hand calculating the size each time is needed, by a range
        structure containing a pointer and a size.  This removes duplicate
        times where the size is calculated.
     *  Tweak kexec_get_cpu().  Don't fail if a cpu is offline because it
        may already have crash notes, and may be up by the time a crash
        happens.  Split the error conditions up to return ERANGE for an
        out-of-range cpu request rather than EINVAL.  Finally, returning a
        range of zeros is acceptable, so do this in preference to failing.
    Changes since v3:
     *  Alter the spinlocks to avoid calling xmalloc/xfree while holding
        the lock.
     *  Tidy up the coding style used.
    Changes since v2:
     *  Allocate crash_notes dynamically using nr_cpu_ids at boot time,
        rather than statically using NR_CPUS.
     *  Fix the incorrect use of signed integers for cpu id.
     *  Fix collateral damage to do_crashdump_trigger() and
        crashdump_trigger_handler caused by reordering sizeof_note() and
     *  Tweak the issue about returing -ENOMEM from kexec_init_cpu_note().
        No functional change.
     *  Change kexec_get_cpu() to attempt to allocate crash note buffers
        in case we have more free memory now than when the pcpu came up.
     *  Now that there are two codepaths possibly allocating crash notes,
        protect the allocation itself with a spinlock.
    Changes since v1:
     *  Use cpu hotplug notifiers to handle allocating of the notes
        buffers rather than assuming the boot state of cpus will be the
        same as the crash state.
     *  Move crash_notes from being per_cpu.  This is because the kdump
        kernel elf binary put in the crash area is hard coded to physical
        addresses which the dom0 kernel typically obtains at boot time.
        If a cpu is offlined, its buffer should not be deallocated because
        the kdump kernel would read junk when trying to get the crash
        notes.  Similarly, the same problem would occur if the cpu was
        re-onlined later and its crash notes buffer was allocated
     *  Only attempt to allocate buffers if a crash area has been
        specified.  Else, allocating crash note buffers is a waste of
        space.  Along with this, change the test in kexec_get_cpu to
        return -EINVAL if no buffers have been allocated.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Committed-by: Keir Fraser <keir@xxxxxxx>
changeset:   25063:9151dfa96c3a
user:        Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
date:        Fri Mar 16 10:14:38 2012 +0100
    x86/vpmu: small fix for console logging beauty
    Signed-off-by: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
    Committed-by: Jan Beulich <jbeulich@xxxxxxxx>
changeset:   25062:1b68427875f7
user:        Tim Deegan <tim@xxxxxxx>
date:        Thu Mar 15 15:20:37 2012 +0000
    arm: don't use atomic operations to gate non-boot CPUs
    Since the cache is not enabled that early, better not to rely on
    load-linked/store-conditional.  Instead, have the boot CPU call the
    other CPUs by their IDs, just like we do later for proper CPU bringup.
    Signed-off-by: Tim Deegan <tim@xxxxxxx>
    Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
commit 2503d4d5a29e7af8dffd1e11229e11c1917d2ccf
Author: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date:   Thu Mar 1 18:58:27 2012 +0000

    qemu-xen: ignore console disconnect events for console/0
    The first console has a different location compared to other PV devices
    (console, rather than device/console/0) and doesn't obey the xenstore
    state protocol. We already special case the first console in con_init
    and con_initialise, we should also do it in con_disconnect.
    This patch should be applied to 4.1 too.
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

Xen-devel mailing list



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