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

[Xen-devel] [xen-4.3-testing test] 25803: regressions - FAIL



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 25666
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install     fail REGR. vs. 25666
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 25666
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 25666
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 25666
 test-amd64-amd64-xl-qemut-win7-amd64  7 windows-install   fail REGR. vs. 25666

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 25666

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            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-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-freebsd10-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemut-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-freebsd10-i386  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 xen-build-check(1)          blocked n/a
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xl-win7-amd64  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-qemuu-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 xen-build-check(1)          blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 xen-build-check(1)     blocked n/a

version targeted for testing:
 xen                  e3f630b73c159078a6991161c5255048b16d366f
baseline version:
 xen                  ce89055575860c4100370133ab488979a83ad49a

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Joby Poriyath <joby.poriyath@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>
  Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   fail    
 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                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemut-rhel6hvm-amd                           blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-i386-freebsd10-amd64                              blocked 
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          blocked 
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-i386-freebsd10-i386                               blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemut-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-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-i386-xend-qemut-winxpsp3                          blocked 
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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 e3f630b73c159078a6991161c5255048b16d366f
Author: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
Date:   Fri Mar 21 02:56:56 2014 +0100

    PV-GRUB: fix blk access at end of disk
    
    GRUB usually always loads a whole disk track, even if that means going
    beyond the end of the disk.  We thus have to gracefully return an error,
    instead of letting the blkfront go panic.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    (cherry picked from commit 51e18e41e39a682de5a2e60ad86048dc6344efec)
    (cherry picked from commit 03eb5134056d61167e6781eecf7e570b491bda73)

commit 4481b30d5ea980fe469c8dfa1580ba2d107fa12f
Author: Joby Poriyath <joby.poriyath@xxxxxxxxxx>
Date:   Tue Feb 4 18:10:35 2014 +0000

    xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry
    
    menuentry in grub2/grub.cfg uses linux16 and initrd16 commands
    instead of linux and initrd. Due to this RHEL 7 (beta) guest failed to
    boot after the installation.
    
    In addition to this, RHEL 7 menu entries have two different single-quote
    delimited strings on the same line, and the greedy grouping for menuentry
    parsing gets both strings, and the options inbetween.
    
    Signed-off-by: Joby Poriyath <joby.poriyath@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Cc: george.dunlap@xxxxxxxxxx
    (cherry picked from commit dd03048708af072374963d6d0721cc6d4c5f52cf)
    (cherry picked from commit 607d9c98e8161d93fc93dd0e2c3a5b5be57f0d2a)

commit de474025e7f25fa0cdcaaaf923ceb2accf1591fb
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 24 14:19:15 2014 +0000

    libxl: Fix carefd lock leak in save callout
    
    If libxl_pipe fails we leave the carefd locked, which translates to
    the atfork lock remaining held.  This would probably cause the process
    to deadlock shortly afterwards.
    
    Of course libxl_pipe is very unlikely to fail unless things are
    already going very badly.  This bug has not been observed anywhere as
    far as we are aware.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    (cherry picked from commit 7eb73add5de5839f160b902dd894d3aecc10ba0c)
    (cherry picked from commit 4bb3a17449a4472930030a627631f788bb678123)

commit d0c5e6a5e531b726f220a5645f07fae1ef22c41b
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Feb 24 14:19:14 2014 +0000

    libxl: Hold the atfork lock while closing carefd
    
    This avoids the process being forked while a carefd is recorded in the
    list but the actual fd has been closed.  If that happened, a
    subsequent libxl_postfork_child_noexec would attempt to close the fd
    again.  If we are lucky that results in a harmless warning; but if we
    are unlucky the fd number has been reused and we close an unrelated
    fd.
    
    This race has not been observed anywhere as far as we are aware.
    
    Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    (cherry picked from commit 2a0c3a62ea4ad6c6bcbf80122b070f3ff3fe7dae)
    (cherry picked from commit 86c00cb6e2d78d5be861656a1e83956c9de96003)

commit 852d1f224dc29d0398b378b3a8a1d2c9c2c2bc8e
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:54:46 2014 +0200

    VMX: fix PAT value seen by guest
    
    The XSA-60 fixes introduced a window during which the guest PAT gets
    forced to all zeros. This shouldn't be visible to the guest. Therefore
    we need to intercept PAT MSR accesses during that time period.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Liu Jinsong <jinsong.liu@xxxxxxxxx>
    master commit: fce79f8ce91dc45f3a4d699ee67c49e6cbeb1197
    master date: 2014-04-01 16:49:18 +0200

commit 015fd7910b15243d17ff79ed887a5fdb43fa0629
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:54:10 2014 +0200

    x86/EPT: relax treatment of APIC MFN
    
    There's no point in this being mapped UC by the guest due to using a
    respective PAT index - set the ignore-PAT flag to true.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: 1f8b57779785bf9f55c16312bb1ec679929c314b
    master date: 2014-03-28 13:43:25 +0100

commit e7516b4015c87dc0e136352d8b6a1c850ebdda3f
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:53:20 2014 +0200

    x86/HVM: correct CPUID leaf 80000008 handling
    
    CPUID[80000008].EAX[23:16] have been given the meaning of the guest
    physical address restriction (in case it needs to be smaller than the
    host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
    
    Enforce a lower limit at the same time, as well as a fixed value for
    the virtual address bits, and zero for the guest physical address ones.
    
    In order for the vMTRR code to see these overrides we need to make it
    call hvm_cpuid() instead of domain_cpuid(), which in turn requires
    special casing (and relaxing) the controlling domain.
    
    This additionally should hide an ordering problem in the tools: Both
    xend and xl appear to be restoring a guest from its image before
    setting up the CPUID policy in the hypervisor, resulting in
    domain_cpuid() returning all zeros and hence the check in
    mtrr_var_range_msr_set() failing if the guest previously had more than
    the minimum 36 physical address bits.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: ef437690af8b75e6758dce77af75a22b63982883
    master date: 2014-03-28 13:33:34 +0100

commit da44176cc1b45558f8ec53ef7f5e8796372f57a9
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:52:36 2014 +0200

    x86: fix determination of bit count for struct domain allocations
    
    We can't just add in the hole shift value, as the hole may be at or
    above the 44-bit boundary. Instead we need to determine the total bit
    count until reaching 32 significant (not squashed out) bits in PFN
    representations.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: b3d2f8b2cba9fce5bc8995612d0d13fcefec7769
    master date: 2014-03-24 10:48:03 +0100

commit e2aa3f21e5b1746913f7d4605f631d383c7f2551
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:51:27 2014 +0200

    x86/Intel: work around Xeon 7400 series erratum AAI65
    
    Linux commit 40e2d7f9b5dae048789c64672bf3027fbb663ffa ("x86 idle:
    Repair large-server 50-watt idle-power regression") tells us that this
    applies not just to the named Xeon 7400 series, but also NHM-EX and
    WSM-EX; sadly Intel's documentation is so badly searchable that I
    wasn't able to locate the respective errata (and hence can't quote
    their numbers here).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    master commit: 96d1b237ae9b2f2718bb1c59820701f17d3d86e0
    master date: 2014-03-17 16:47:22 +0100

commit 6c63041428cc348bcb2887afabd606bc4bd5523f
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:50:30 2014 +0200

    VT-d: fix RMRR handling
    
    Removing mapped RMRR tracking structures in dma_pte_clear_one() is
    wrong for two reasons: First, these regions may cover more than a
    single page. And second, multiple devices (and hence multiple devices
    assigned to any particular guest) may share a single RMRR (whether
    assigning such devices to distinct guests is a safe thing to do is
    another question).
    
    Therefore move the removal of the tracking structures into the
    counterpart function to the one doing the insertion -
    intel_iommu_remove_device(), and add a reference count to the tracking
    structure.
    
    Further, for the handling of the mappings of the respective memory
    regions to be correct, RMRRs must not overlap. Add a respective check
    to acpi_parse_one_rmrr().
    
    And finally, with all of this being VT-d specific, move the cleanup
    of the list as well as the structure type definition where it belongs -
    in VT-d specific rather than IOMMU generic code.
    
    Note that this doesn't address yet another issue associated with RMRR
    handling: The purpose of the RMRRs as well as the way the respective
    IOMMU page table mappings get inserted both suggest that these regions
    would need to be marked E820_RESERVED in all (HVM?) guests' memory
    maps, yet nothing like this is being done in hvmloader. (For PV guests
    this would also seem to be necessary, but may conflict with PV guests
    possibly assuming there to be just a single E820 entry representing all
    of its RAM.)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
    master commit: dd527061770789d8152b1dea68056987b202d87a
    master date: 2014-03-17 16:45:04 +0100

commit 1c20a463f93d30eb3d3a1f036e4ef93d74cd23b3
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:49:51 2014 +0200

    x86: make hypercall preemption checks consistent
    
    - never preempt on the first iteration (ensure forward progress)
    - never preempt on the last iteration (pointless/wasteful)
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: fd7bfce0395ace266159760e35dc49f7af3b90ce
    master date: 2014-03-13 14:27:51 +0100

commit 21ff0c9141472da64c999f4cc2e12d938fe50f83
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Fri Apr 4 10:48:53 2014 +0200

    common: make hypercall preemption checks consistent
    
    - never preempt on the first iteration (ensure forward progress)
    - do cheap checks first
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 8c0eed2cc8d8a2ccccdffe4c386b625b672dc12a
    master date: 2014-03-13 14:26:35 +0100
(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®.