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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  4 xen-install       fail REGR. vs. 18466
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 18466
 test-amd64-i386-qemut-rhel6hvm-amd  4 xen-install         fail REGR. vs. 18466
 test-amd64-amd64-xl           4 xen-install               fail REGR. vs. 18466
 test-amd64-amd64-pv           4 xen-install               fail REGR. vs. 18466
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 18466
 test-amd64-i386-qemuu-rhel6hvm-amd  4 xen-install         fail REGR. vs. 18466
 test-amd64-amd64-pair         6 xen-install/dst_host      fail REGR. vs. 18466
 test-amd64-amd64-pair         5 xen-install/src_host      fail REGR. vs. 18466
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 18466
 test-amd64-amd64-xl-qemut-win7-amd64  4 xen-install       fail REGR. vs. 18466
 test-amd64-amd64-xl-qemuu-winxpsp3  4 xen-install         fail REGR. vs. 18466
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 18466
 test-amd64-amd64-xl-qemuu-win7-amd64  4 xen-install       fail REGR. vs. 18466
 test-amd64-i386-qemut-rhel6hvm-intel  4 xen-install       fail REGR. vs. 18466
 test-amd64-amd64-xl-win7-amd64  4 xen-install             fail REGR. vs. 18466
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 18466
 test-amd64-i386-xl-qemut-win7-amd64  4 xen-install        fail REGR. vs. 18466
 test-amd64-amd64-xl-winxpsp3  4 xen-install               fail REGR. vs. 18466
 test-amd64-amd64-xl-qemut-winxpsp3  4 xen-install         fail REGR. vs. 18466
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 18466
 test-amd64-i386-xend-qemut-winxpsp3  4 xen-install        fail REGR. vs. 18466
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 18466
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 18466
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 18466
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 18466
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 18466
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  4 xen-install   fail REGR. vs. 18466

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  4 xen-install            fail REGR. vs. 18466
 test-amd64-amd64-xl-sedf-pin  4 xen-install               fail REGR. vs. 18466
 test-amd64-amd64-xl-sedf      4 xen-install               fail REGR. vs. 18466

version targeted for testing:
 xen                  2a6327bf2bfaf5de5e07aed583d2c337c9d368c0
baseline version:
 xen                  d4435fe5e2f0dfadb41ef46c38f462f45d67762e

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Eric Trudeau <etrudeau@xxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 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-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
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
    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 2a6327bf2bfaf5de5e07aed583d2c337c9d368c0
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Fri Apr 26 11:58:47 2013 +0100

    xen: arm: drop LDFLAGS_DIRECT emulation specification.
    
    The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring 
due
    to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu 
gcc
    bug, hwever when investigating I found that this option was not necessary at
    all since we provide an explicit linker script when linking the hypervisor
    (AFAICT all -m<foo> does is override the default linker script).
    
    LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files 
but
    -m<emulatin> is not needed for this since it isn't linking the final image 
and
    we are calling the linker with the correct, cross if necessary, name.
    
    However it does appear to be potentially useful to supply -EL in both cases 
to
    ensure that we get little endian images. (I just happened to spot that Linux
    does this, for both arm and arm64, although I expect we are unlikely to trip
    over such toolchains these days).
    
    Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>

commit bbccf0d088d2041d95ede1d59fc195205f932f38
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Apr 25 15:45:50 2013 +0100

    xen: arm: enable aborts on all physical processors.
    
    I'm not sure how this ended up in construct dom0 where it only affects the
    boot cpu and doesn't logically fit.
    
    Enable aborts at the same time as we enable interrupts.
    
    I'm not sure what the behaviour of an "abort worthy" operation while aborts
    are disable is, but it must surely be worse than calling do_unexpected_trap,
    which is what happens from now on.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>

commit c57c50c1de759583d5de629fec205254280da4f0
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Wed Jul 17 12:18:51 2013 +0100

    xen: arm: clear the exclusive monitor on exception return
    
    Otherwise context switching between two vcpus which are contending the same
    lock can result in a spurious success.
    
    Our spinlock and atomics code (which we get from Linux) rely on this 
behaviour
    because they use non-exclusive stores for single instruction operations 
(e.g.
    spin_unlock or atomic_set).
    
    This is not required on ARMv8 since eret implicitly clears the monitor.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>

commit 47d1a51480ad0f602d747e460d619436c907deea
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Fri Jul 12 12:54:42 2013 +0100

    xen: arm: make zImage the default target which we install
    
    The zImage compatible binary is the useful one on real hardware. The 
relocated
    ELF thing is only really useful when booting directly on Fast Models. The
    customary suffix for that case is .axf so provide that as a target.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>

commit 2f044a6a6e4cb0ea24c856c1615e3fb878af2cfb
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Jul 18 09:41:43 2013 +0100

    xen: allow architecture to choose how/whether to compress installed xen 
binary
    
    This is a follow up to "xen: arm: make zImage the default target which we
    install".
    
    On ARM the xen.gz binary installed into /boot is not immediately useful 
because
    bootloaders (e.g. u-boot) do not unconditionally support decompression 
(except
    via the uImage wrapper, which we currently do not support via our build 
system)
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 23e37f599e8bc220aca9abd097171ee17f5630ab
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Jul 18 09:41:42 2013 +0100

    xen: Use $(T) and $(D) aliases in install target
    
    This is consistent with the uninstall target and also shortens some longish
    lines.
    
    Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 524b93def23b9f75fd7851063f5291886e63d1ed
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Thu Jul 18 09:41:41 2013 +0100

    xen: x86: drop the ".gz" suffix when installing
    
    As Jan says it is pretty meaningless under /boot anyway. However I am 
slightly
    concerned about breaking bootloaders (or more specifically their help 
scripts
    which automatically generate config files). By inspection at least grub 2's
    update-grub script (as present in Debian Wheezy) seems to cope (it matches 
on
    xen* not xen*.gz)
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 09a08ef52a21d171cc48b54a975f13e7704c912f
Author: Julien Grall <julien.grall@xxxxxxxxxx>
Date:   Thu Jul 18 14:33:43 2013 +0100

    xen/arm: Implement MPIDR per VCPU
    
    Use different affinity for each VCPU and always expose an SMP systems to
    the guest.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    [ ijc -- s/AFFO/AFF0/ in a comment ]

commit 47193a4437f18cce75230e0fb1ca3b3c78fec7b0
Author: Eric Trudeau <etrudeau@xxxxxxxxxxxx>
Date:   Fri Jul 12 13:30:48 2013 -0400

    xen/arm: Clear the IRQ_GUEST bit in desc->status when releasing an IRQ
    
    While adding support for guest domU IRQs, I noticed that release_irq did
    not clear the IRQ_GUEST bit in the IRQ's desc->status field.
    This is probably not a big deal since not many situations are likely to 
arise
    where an IRQ is sometimes host and sometimes guest.
    
    Signed-off-by: Eric Trudeau <etrudeau@xxxxxxxxxxxx>
    Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

commit 3eb214917f45e567af87605c06c28cea4208faf4
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Jul 18 13:32:12 2013 +0200

    VT-d: enable for multi-vector MSI
    
    The main change being to make alloc_remap_entry() capable of allocating
    a block of entries.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>

commit e36e07bc9b0be0d899d4dd0ea675f6c225dafe5c
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Jul 18 10:05:14 2013 +0200

    x86: fix cache flushing condition in map_pages_to_xen()
    
    This fixes yet another shortcoming of the function (exposed by 8bfaa2c2
    ["x86: add locking to map_pages_to_xen()"]'s adjustment to
    msix_put_fixmap()): It must not flush caches when transitioning to a
    non-present mapping. Doing so causes the CLFLUSH to fault, if used in
    favor of WBINVD.
    
    To help code readability, factor out the whole flush flags updating
    in map_pages_to_xen() into a helper macro.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>

commit 915a59f25c5eddd86bc2cae6389d0ed2ab87e69e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jul 18 09:16:15 2013 +0200

    x86/time: Update wallclock in shared info when altering domain time offset
    
    domain_set_time_offset() udpates d->time_offset_seconds, but does not 
correct
    the wallclock in the shared info, meaning that it is incorrect until the 
next
    XENPF_settime hypercall from dom0 which resynchronises the wallclock for all
    domains.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
(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®.