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

[Xen-devel] [xen-4.2-testing test] 16140: trouble: fail/pass/preparing



flight 16140 xen-4.2-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16140/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-pcipt-intel  2 hosts-allocate        running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-amd  2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pv           2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-amd  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-credit2    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-multivcpu  2 hosts-allocate           running [st=running!]
 test-i386-i386-pv             2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl           2 hosts-allocate           running [st=running!]
 test-amd64-i386-pv            2 hosts-allocate           running [st=running!]
 test-i386-i386-xl             2 hosts-allocate           running [st=running!]
 test-amd64-i386-xl            2 hosts-allocate           running [st=running!]
 test-amd64-i386-qemuu-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-i386-qemut-rhel6hvm-intel  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-sedf      2 hosts-allocate           running [st=running!]
 test-amd64-amd64-pair         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-i386-pair          2 hosts-allocate           running [st=running!]
 test-i386-i386-pair           2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemut-win   2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win7-amd64  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xl-win7-amd64  2 hosts-allocate          running [st=running!]
 test-amd64-i386-qemut-win     2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-win       2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemut-win7-amd64  2 hosts-allocate   running [st=running!]
 test-amd64-amd64-xl-qemut-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 2 hosts-allocate running [st=running!]
 test-i386-i386-xl-winxpsp3    2 hosts-allocate           running [st=running!]
 test-i386-i386-xl-qemuu-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemut-win  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-qemut-win7-amd64  2 hosts-allocate    running [st=running!]
 test-amd64-i386-xl-qemut-win-vcpus1  2 hosts-allocate    running [st=running!]
 test-i386-i386-xl-qemut-winxpsp3  2 hosts-allocate       running [st=running!]
 test-amd64-i386-xl-win-vcpus1  2 hosts-allocate          running [st=running!]
 test-amd64-i386-xl-winxpsp3-vcpus1  2 hosts-allocate     running [st=running!]
 test-amd64-i386-rhel6hvm-intel  2 hosts-allocate         running [st=running!]
 test-amd64-i386-xend-winxpsp3  2 hosts-allocate          running [st=running!]
 test-i386-i386-xl-win         2 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-winxpsp3  2 hosts-allocate           running [st=running!]
 test-amd64-i386-win           2 hosts-allocate           running [st=running!]
 test-amd64-amd64-win          2 hosts-allocate           running [st=running!]
 test-i386-i386-qemut-win      2 hosts-allocate           running [st=running!]
 test-i386-i386-win            2 hosts-allocate           running [st=running!]
 test-amd64-i386-win-vcpus1    2 hosts-allocate           running [st=running!]
 test-amd64-i386-xend-qemut-winxpsp3  2 hosts-allocate    running [st=running!]
 test-amd64-i386-qemut-win-vcpus1  2 hosts-allocate       running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3  2 hosts-allocate     running [st=running!]
 test-amd64-amd64-qemut-win    2 hosts-allocate           running [st=running!]

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass

version targeted for testing:
 xen                  94cfa1b6e178
baseline version:
 xen                  c713f1f7d3c1

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@xxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  David Scott <dave.scott@xxxxxxxxxxxxx>
  Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Phil Evans <Phil.Evans@xxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
  Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

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


------------------------------------------------------------
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.

------------------------------------------------------------
changeset:   25987:94cfa1b6e178
tag:         tip
user:        Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
date:        Tue Feb 12 13:44:02 2013 +0100
    
    VMX: disable SMEP feature when guest is in non-paging mode
    
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    
    Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
    xen-unstable changeset: 26502:d1bf3b21f783
    xen-unstable date: Wed Jan 30 17:17:30 UTC 2013
    
    
changeset:   25986:51f6ae41fd7e
user:        Keir Fraser <keir@xxxxxxx>
date:        Tue Feb 12 13:43:16 2013 +0100
    
    vmx: Simplify cr0 update handling by deferring cr4 changes to the cr4 
handler.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 26501:8201b6ec3564
    xen-unstable date: Wed Jan 30 17:15:39 UTC 2013
    
    
changeset:   25985:f3a2642c52e4
user:        Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx>
date:        Tue Feb 12 13:41:37 2013 +0100
    
    fix acpi_dmar_zap/reinstate() (fixes S3 regression)
    
    Fix S3 regression introduced by cs 23013:65d26504e843 (ACPI: large
    cleanup). The dmar virtual pointer returned from acpi_get_table cannot
    be safely stored away and used later, as the underlying
    acpi_os_map_memory / __acpi_map_table functions overwrite the mapping
    causing it to point to different tables than dmar (last fetched table is
    used). This subsequently causes acpi_dmar_reinstate() and
    acpi_dmar_zap() to write data to wrong table, causing its corruption and
    problems with consecutive s3 resumes.
    
    Added a new function to fetch ACPI table physical address, and
    establishing separate static mapping for dmar_table pointer instead of
    using acpi_get_table().
    
    Signed-off-by: Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx>
    
    Added call to acpi_tb_verify_table(). Fixed page count passed to
    map_pages_to_xen(). Cosmetic changes.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    xen-unstable changeset: 26443:9efe4c0bf9c8
    xen-unstable date: Wed Jan 23 09:31:04 UTC 2013
    
    
changeset:   25984:60e9576338b6
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Tue Feb 12 13:40:36 2013 +0100
    
    x86: restore (optional) forwarding of PCI SERR induced NMI to Dom0
    
    c/s 22949:54fe1011f86b removed the forwarding of NMIs to Dom0 when they
    were caused by PCI SERR. NMI buttons as well as BMCs (like HP's iLO)
    may however want such events to be seen in Dom0 (e.g. to trigger a
    dump).
    
    Therefore restore most of the functionality which named c/s removed
    (adjusted for subsequent changes, and adjusting the public interface to
    use the modern term, retaining the old one for backwards
    compatibility).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 26440:5af4f2ab06f3
    xen-unstable date: Tue Jan 22 08:33:10 UTC 2013
    
    
changeset:   25983:c82378694acf
user:        Tim Deegan <tim@xxxxxxx>
date:        Tue Feb 12 13:39:30 2013 +0100
    
    x86/hvm: fix RTC setting.
    
    When the guest writes one field of the RTC time, we must bring all the
    other fields up to date for the current second before calculating the
    new RTC time.
    
    Signed-off-by: Tim Deegan <tim@xxxxxxx>
    Tested-by: Phil Evans <Phil.Evans@xxxxxxxx>
    xen-unstable changeset: 26428:9e8c39bdc1fe
    xen-unstable date: Fri Jan 18 11:31:57 UTC 2013
    
    
changeset:   25982:154e4909ff55
user:        Boris Ostrovsky <boris.ostrovsky@xxxxxxx>
date:        Tue Feb 12 13:38:22 2013 +0100
    
    x86/AMD: Enable WC+ memory type on family 10 processors
    
    In some cases BIOS may not enable WC+ memory type on family 10 processors,
    instead converting what would be WC+ memory to CD type. On guests using
    nested pages this could result in performance degradation. This patch
    enables WC+.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxx>
    xen-unstable changeset: 26427:8f6dd5dc5d6c
    xen-unstable date: Fri Jan 18 11:20:58 UTC 2013
    
    
changeset:   25981:5b3c15526555
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Tue Feb 12 13:37:15 2013 +0100
    
    x86: consistently mask floating point exceptions
    
    c/s 23142:f5e8d152a565 resulted in v->arch.fpu_ctxt to point into the
    save area allocated for xsave/xrstor (when they're available). The way
    vcpu_restore_fpu_lazy() works (using fpu_init() for an uninitialized
    vCPU only when there's no xsave support) causes this to load whatever
    arch_set_info_guest() put there, irrespective of whether the i387 state
    was specified to be valid in the respective input structure.
    
    Consequently, with a cleared (al zeroes) incoming FPU context, and with
    xsave available, one gets all exceptions unmasked (as opposed to to the
    legacy case, where FINIT and LDMXCSR get used, masking all exceptions).
    This causes e.g. para-virtualized NetWare to crash.
    
    The behavior of arch_set_info_guest() is thus being made more hardware-
    like for the FPU portion of it: Considering it to be similar to INIT,
    it will leave untouched all floating point state now. An alternative
    would be to make the behavior RESET-like, forcing all state to known
    values, albeit - taking into account legacy behavior - not to precisely
    the values RESET would enforce (which masks only SSE exceptions, but
    not x87 ones); that would come closest to mimicing FINIT behavior in
    the xsave case. Another option would be to continue copying whatever
    was provided, but override (at least) FCW and MXCSR if VGCF_I387_VALID
    isn't set.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 26395:b4cbb83f9a1f
    xen-unstable date: Wed Jan 16 12:56:55 UTC 2013
    
    
changeset:   25980:0bc9a0996a6b
user:        Dario Faggioli <dario.faggioli@xxxxxxxxxx>
date:        Tue Feb 12 13:36:07 2013 +0100
    
    xen: sched_credit: improve picking up the idle CPU for a VCPU
    
    In _csched_cpu_pick() we try to select the best possible CPU for
    running a VCPU, considering the characteristics of the underlying
    hardware (i.e., how many threads, core, sockets, and how busy they
    are). What we want is "the idle execution vehicle with the most
    idling neighbours in its grouping".
    
    In order to achieve it, we select a CPU from the VCPU's affinity,
    giving preference to its current processor if possible, as the basis
    for the comparison with all the other CPUs. Problem is, to discount
    the VCPU itself when computing this "idleness" (in an attempt to be
    fair wrt its current processor), we arbitrarily and unconditionally
    consider that selected CPU as idle, even when it is not the case,
    for instance:
     1. If the CPU is not the one where the VCPU is running (perhaps due
        to the affinity being changed);
     2. The CPU is where the VCPU is running, but it has other VCPUs in
        its runq, so it won't go idle even if the VCPU in question goes.
    
    This is exemplified in the trace below:
    
    ]  3.466115364 x|------|------| d10v1   22005(2:2:5) 3 [ a 1 8 ]
       ... ... ...
       3.466122856 x|------|------| d10v1 runstate_change d10v1
       running->offline
       3.466123046 x|------|------| d?v? runstate_change d32767v0
       runnable->running
       ... ... ...
    ]  3.466126887 x|------|------| d32767v0   28004(2:8:4) 3 [ a 1 8 ]
    
    22005(...) line (the first line) means _csched_cpu_pick() was called
    on VCPU 1 of domain 10, while it is running on CPU 0, and it choose
    CPU 8, which is busy ('|'), even if there are plenty of idle
    CPUs. That is because, as a consequence of changing the VCPU affinity,
    CPU 8 was chosen as the basis for the comparison, and therefore
    considered idle (its bit gets unconditionally set in the bitmask
    representing the idle CPUs). 28004(...) line means the VCPU is woken
    up and queued on CPU 8's runq, where it waits for a context switch or
    a migration, in order to be able to execute.
    
    This change fixes things by only considering the "guessed" CPU idle if
    the VCPU in question is both running there and is its only runnable
    VCPU.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
    xen-unstable changeset: 26287:127c2c47d440
    xen-unstable date: Tue Dec 18 18:10:18 UTC 2012
    
    
changeset:   25979:c713f1f7d3c1
user:        Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
date:        Thu Feb 07 14:24:08 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    Signed-off-by: David Scott <dave.scott@xxxxxxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    xen-unstable changeset: 26522:ffd30e7388ad
    Backport-requested-by: security@xxxxxxx
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
========================================
commit ad6cb8a6550d0f0550252db4e05c305086ea9a65
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 2a1354d655d816feaad7dbdb8364f40a208439c1)

_______________________________________________
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®.