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

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

flight 8664 xen-unstable real [real]

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-xl-credit2   14 guest-localmigrate/x10     fail REGR. vs. 8652

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  fc2be6cb89ad
baseline version:
 xen                  8d6edc3d26d2

People who touched revisions under test:
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Wei Wang <wei.wang2@xxxxxxx>

 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        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

Test harness code can be found at

Not pushing.

changeset:   23771:fc2be6cb89ad
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Aug 16 15:05:55 2011 +0100
    x86: simplify (and fix) clear_IO_APIC{,_pin}()
    These are used during bootup and (emergency) shutdown only, and their
    only purpose is to get the actual IO-APIC's RTE(s) cleared.
    Consequently, only the "raw" accessors should be used (and the ones
    going through interrupt remapping code can be skipped), with the
    exception of determining the delivery mode: This one must always go
    through the interrupt remapping path, as in the VT-d case the actual
    IO-APIC's RTE will have the delivery mode always set to zero (which
    before possibly could have resulted in such an entry getting cleared
    in the "raw" pass, though I haven't observed this case in practice).
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23770:5c1ebc117f99
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Aug 16 15:05:30 2011 +0100
    passthrough: don't use open coded IO-APIC accesses
    This makes the respective functions quite a bit more legible.
    Since this requires fiddling with __ioapic_{read,write}_entry()
    make them and their wrappers have their argument types match those of
    __io_apic_{read,write}() (int -> unsigned int).
    No functional change intended.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23769:f1e66f813b9b
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Aug 16 15:05:03 2011 +0100
    x86-64/mmcfg: relax base address restriction
    Following what Linux did quite a while ago, don't generally disallow
    MMCFG base addresses to live above the 4Gb boundary: New systems are
    assumed to be fine, and SGI ones are, too.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23768:09595fdf3638
user:        Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
date:        Tue Aug 16 15:04:19 2011 +0100
    Revert 23733:fbf3768e5934 "AMD IOMMU: remove global ..."
    23733:fbf3768e5934 causes xen-unstable not to boot on several of the
    xen.org AMD test systems.  We get an endless series of these:
      (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x00a0, fault
      address = 0xfdf8f10144
    I have constructed the attached patch which reverts c/s 23733
    (adjusted for conflicts due to subsequent patches).  With this
    reversion Xen once more boots on these machines.
    23733 has been in the tree for some time now, causing this breakage,
    and has already been fingered by the automatic bisector and discussed
    on xen-devel as the cause of boot failures.  I think it is now time to
    revert it pending a correct fix to the original problem.
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23767:80e9fcdaef36
user:        Wei Wang <wei.wang2@xxxxxxx>
date:        Tue Aug 16 15:03:11 2011 +0100
    amd iommu: Automatic page coalescing
    This patch implements automatic page coalescing when separated io page
    table is used. It uses ignore bits in iommu pde to cache how many
    entries lower next page level are suitable for coalescing and then
    builds a super page entry when all lower entries are contiguous.  This
    patch has been tested OK for weeks mainly with graphic devices and 3D
    mark vantage.
    Signed-off-by: Wei Wang <wei.wang2@xxxxxxx>
changeset:   23766:8d6edc3d26d2
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Aug 13 10:14:58 2011 +0100
    x86/PCI-MSI: properly determine VF BAR values
    As was discussed a couple of times on this list, SR-IOV virtual
    functions have their BARs read as zero - the physical function's
    SR-IOV capability structure must be consulted instead. The bogus
    warnings people complained about are being eliminated with this
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
commit cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Tue Jun 28 13:50:53 2011 +0100

    qemu-char.c: fix incorrect CONFIG_STUBDOM handling
    qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef]
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Xen-devel mailing list



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