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

[Xen-devel] [xen-4.3-testing test] 21989: FAIL



flight 21989 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/21989/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                  2 host-install(2) broken in 21984 REGR. vs. 21888
 build-armhf                   3 capture-logs    !broken in 21984 [st=!broken!]
 build-armhf-pvops            2 host-install(2) broken in 21984 REGR. vs. 21888
 build-armhf-pvops             3 capture-logs    !broken in 21984 [st=!broken!]

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 21984

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-armhf-armhf-xl           1 xen-build-check(1)        blocked in 21984 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 21984 never pass

version targeted for testing:
 xen                  2df9704ad1bb7484efded4fec9e81f13fab4e839
baseline version:
 xen                  be2f2316f11d56555a37873d3f53bb3f46dec856

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Kouya Shimura <kouya@xxxxxxxxxxxxxx>
  Nathan Studer <nate.studer@xxxxxxxxxxxxxxx>
  Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
  Tim Deegan <tim@xxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 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-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                                   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-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 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 2df9704ad1bb7484efded4fec9e81f13fab4e839
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:29:57 2013 +0100

    x86: eliminate has_arch_mmios()
    
    ... as being generally insufficient: Either has_arch_pdevs() or
    cache_flush_permitted() should be used (in particular, it is
    insufficient to consider MMIO ranges alone - I/O port ranges have the
    same requirements if available to a guest).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 79233938ab2a8f273fd5dcdbf8e8381b9eb3a461
    master date: 2013-11-12 16:28:47 +0100

commit ec6f0183517615823641785233eeaf8372f674ac
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:28:37 2013 +0100

    VMX: don't crash processing 'd' debug key
    
    There's a window during scheduling where "current" and the active VMCS
    may disagree: The former gets set much earlier than the latter. Since
    both vmx_vmcs_enter() and vmx_vmcs_exit() immediately return when the
    subject vCPU is "current", accessing VMCS fields would, depending on
    whether there is any currently active VMCS, either read wrong data, or
    cause a crash.
    
    Going forward we might want to consider reducing the window during
    which vmx_vmcs_enter() might fail (e.g. doing a plain __vmptrld() when
    v->arch.hvm_vmx.vmcs != this_cpu(current_vmcs) but arch_vmx->active_cpu
    == -1), but that would add complexities (acquiring and - more
    importantly - properly dropping v->arch.hvm_vmx.vmcs_lock) that don't
    look worthwhile adding right now.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 58929248461ecadce13e92eb5a5d9ef718a7c88e
    master date: 2013-11-12 11:52:19 +0100

commit 9aa5c832e967ae333caef477521d055c1c49c31e
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:28:05 2013 +0100

    nested SVM: adjust guest handling of structure mappings
    
    For one, nestedsvm_vmcb_map() error checking must not consist of using
    assertions: Global (permanent) mappings can fail, and hence failure
    needs to be dealt with properly. And non-global (transient) mappings
    can't fail anyway.
    
    And then the I/O port access bitmap handling was broken: It checked
    only to first of the accessed ports rather than each of them.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Christoph Egger <chegger@xxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    master commit: b1e87805bf37b446dade93a7eb922bb7d1269756
    master date: 2013-11-12 11:51:15 +0100

commit b54a623efbcf5bff25c55117add1b4427b4e2f1b
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Fri Nov 15 11:27:24 2013 +0100

    numa-sched: leave node-affinity alone if not in "auto" mode
    
    If the domain's NUMA node-affinity is being specified by the
    user/toolstack (instead of being automatically computed by Xen),
    we really should stick to that. This means domain_update_node_affinity()
    is wrong when it filters out some stuff from there even in "!auto"
    mode.
    
    This commit fixes that. Of course, this does not mean node-affinity
    is always honoured (e.g., a vcpu won't run on a pcpu of a different
    cpupool) but the necessary logic for taking into account all the
    possible situations lives in the scheduler code, where it belongs.
    
    What could happen without this change is that, under certain
    circumstances, the node-affinity of a domain may change when the
    user modifies the vcpu-affinity of the domain's vcpus. This, even
    if probably not a real bug, is at least something the user does
    not expect, so let's avoid it.
    
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 67348c3ac700b8bc9147638c719c3035c5ef20f5
    master date: 2013-11-12 10:54:28 +0100

commit e1c1672e9be7886dd50ddd8605855783d7d25e9b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:26:30 2013 +0100

    x86/EFI: make trampoline allocation more flexible
    
    Certain UEFI implementations reserve all memory below 1Mb at boot time,
    making it impossible to properly allocate the chunk necessary for the
    trampoline. Fall back to simply grabbing a chunk from EfiBootServices*
    regions immediately prior to calling ExitBootServices().
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
    master date: 2013-11-08 11:08:32 +0100

commit cd766e12d4c914f3928537acb64595f5044d43bf
Author: Kouya Shimura <kouya@xxxxxxxxxxxxxx>
Date:   Fri Nov 15 11:25:46 2013 +0100

    x86/hvm: fix restart of RTC periodic timer with vpt_align=1
    
    The commit 58afa7ef "x86/hvm: Run the RTC periodic timer on a
    consistent time series" aligns the RTC periodic timer to the VM's boot time.
    However, it's aligned later again to the system time in 
create_periodic_time()
    with vpt_align=1. The next tick might be skipped.
    
    Signed-off-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    master commit: 48535f5798e3e237d9920a74c1ce3802958136c0
    master date: 2013-11-08 11:07:14 +0100

commit 406323bdf652767fa2168e5ea4dfaf619d67867b
Author: Nathan Studer <nate.studer@xxxxxxxxxxxxxxx>
Date:   Fri Nov 15 11:25:05 2013 +0100

    call sched_destroy_domain before cpupool_rm_domain
    
    The domain destruction code, removes a domain from its cpupool
    before attempting to destroy its scheduler information.  Since
    the scheduler framework uses the domain's cpupool information
    to decide on which scheduler ops to use, this results in the
    the wrong scheduler's destroy domain function being called
    when the cpupool scheduler and the initial scheduler are
    different.
    
    Correct this by destroying the domain's scheduling information
    before removing it from the pool.
    
    Signed-off-by: Nathan Studer <nate.studer@xxxxxxxxxxxxxxx>
    Reviewed-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 117f67350fd18b11ab09d628b4edea3364b09441
    master date: 2013-11-06 10:21:09 +0100

commit c179b2fd803b8b6cc29046088a90791a65d9cb32
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:24:16 2013 +0100

    x86/HVM: 32-bit IN result must be zero-extended to 64 bits
    
    Just like for all other operations with 32-bit operand size.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    
    x86/HVM: 32-bit IN result must be zero-extended to 64 bits (part 2)
    
    Just spotted a counterpart of what commit 9d89100b (same title) dealt
    with.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 9d89100ba8b7b02adb7c2e89ef7c81e734942e7c
    master date: 2013-11-05 14:51:53 +0100
    master commit: 1e521eddeb51a9f1bf0e4dd1d17efc873eafae41
    master date: 2013-11-15 11:01:49 +0100

commit ff8c797392bddc04a35463958bfc2d981734d345
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:23:04 2013 +0100

    x86: make sure memory block is RAM before passing to the allocator
    
    Memory blocks outside of the always visible 1:1 mapping range get
    passed to the allocator separately (once enough other setup was done).
    Skipping non-RAM regions, however, was forgotten in adc5afbf ("x86:
    support up to 16Tb").
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 227258983401b7e6091967ffaf22ad83f4ebaf6f
    master date: 2013-11-04 14:29:24 +0100

commit 53b20077f9f15cd78bad42bfdd98e27c7fe32d5e
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:22:24 2013 +0100

    x86/ACPI/x2APIC: guard against out of range ACPI or APIC IDs
    
    Other than for the legacy APIC, the x2APIC MADT entries have valid
    ranges possibly extending beyond what our internal arrays can handle,
    and hence we need to guard ourselves against corrupting memory here.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Keir Fraser <keir@xxxxxxx>
    master commit: 2c24cdcce3269f3286790c63821951a1de93c66a
    master date: 2013-11-04 10:10:04 +0100

commit 5c1dcf7d2c03fc9f256313cf99bfd81bddcc967d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:20:55 2013 +0100

    x86: refine address validity checks before accessing page tables
    
    In commit 40d66baa ("x86: correct LDT checks") and d06a0d71 ("x86: add
    address validity check to guest_map_l1e()") I didn't really pay
    attention to the fact that these checks would better be done before the
    paging_mode_translate() ones, as there's also no equivalent check down
    the shadow code paths involved here (at least not up to the first use
    of the address), and such generic checks shouldn't really be done by
    particular backend functions anyway.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    master commit: 343cad8c70585c4dba8afc75e1ec1b7610605ab2
    master date: 2013-10-28 12:00:36 +0100

commit 92503639bd8bedd7f9097629f77e2de5a31659b2
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Nov 15 11:20:04 2013 +0100

    x86/xsave: also save/restore XCR0 across suspend (ACPI S3)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: e47a90e6dca491c0ceea6ffa18055e7e32565e8e
    master date: 2013-10-21 17:26:16 +0200
(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®.