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

[Xen-devel] [xen-unstable test] 8710: FAIL

flight 8710 xen-unstable real [real]

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-pair         3 host-install/src_host(3)     broken   in 8705

Tests which are failing intermittently (not blocking):
 test-i386-i386-win           14 guest-start.2                fail pass in 8705
 test-amd64-i386-xl-credit2    9 guest-start          fail in 8705 pass in 8710

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-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check       fail in 8705 never pass

version targeted for testing:
 xen                  7ba9270b127b
baseline version:
 xen                  fc2be6cb89ad

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Christoph Egger <Christoph.Egger@xxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Tim Deegan <tim@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                                   pass    
 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:   23778:7ba9270b127b
tag:         tip
user:        Tim Deegan <tim@xxxxxxx>
date:        Fri Aug 19 13:29:27 2011 +0100
    nestedhvm: avoid endless loop of nested page faults
    Stop sending IPIs to flush the nested-on-nested pagetable
    after write operations. Instead flush the TLB only.
    This fixes an endless loop of nested page faults after
    adding an entry to the nested-on-nested pagetable.
    Signed-off-by: Christoph Egger <Christoph.Egger@xxxxxxx>
    Committed-by: Tim Deegan <tim@xxxxxxx>
changeset:   23777:e86b85dc6820
user:        Tim Deegan <tim@xxxxxxx>
date:        Fri Aug 19 13:29:25 2011 +0100
    nestedhvm: do not send IPIs twice
    In p2m_get_nestedp2m() there is no need to send IPIs via
    nestedhvm_vmcx_flushtlb() since p2m_flush_table() already
    did that.
    Signed-off-by: Christoph Egger <Christoph.Egger@xxxxxxx>
    Committed-by: Tim Deegan <tim@xxxxxxx>
changeset:   23776:0ddb4481f883
user:        Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
date:        Fri Aug 19 09:58:22 2011 +0100
    x86/KEXEC: disable hpet legacy broadcasts earlier
    On x2apic machines which booted in xapic mode,
    hpet_disable_legacy_broadcast() sends an event check IPI to all online
    processors.  This leads to a protection fault as the genapic blindly
    pokes x2apic MSRs while the local apic is in xapic mode.
    One option is to change genapic when we shut down the local apic, but
    there are still problems with trying to IPI processors in the online
    processor map which are actually sitting in NMI loops
    Another option is to have each CPU take itself out of the online CPU
    map during the NMI shootdown.
    Realistically however, disabling hpet legacy broadcasts earlier in the
    kexec path is the easiest fix to the problem.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
changeset:   23775:9957bef3e7b4
user:        Jeremy Fitzhardinge <jeremy@xxxxxxxx>
date:        Fri Aug 19 09:57:42 2011 +0100
    mini-os: work around ld bug causing stupid CTOR count
    I'm seeing pvgrub crashing when running CTORs.  It appears its because
    the magic in the linker script is generating junk.  If I get ld to
    output a map, I see:
    .ctors          0x0000000000097000       0x18
                    0x0000000000097000                __CTOR_LIST__ = .
                    0x0000000000097000        0x4 LONG 0x25c04
                    (((__CTOR_END__ - __CTOR_LIST__) / 0x4) - 0x2)
     .ctors         0x0000000000097004       0x10
                    0x0000000000097014        0x4 LONG 0x0
                    0x0000000000097018                __CTOR_END__ = .
    In other words, somehow ((0x97018-0x97000) / 4) - 2 = 0x25c04
    The specific crash is that the ctor loop tries to call the NULL
    sentinel.  I'm seeing the same with the DTOR list.
    Avoid this by terminating the loop with the NULL sentinel, and get rid
    of the CTOR count entirely.
    From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset:   23774:e35c5202625e
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Fri Aug 19 09:55:20 2011 +0100
    x86-64/EFI: construct EDD data from device path protocol information
    In the absence of a BIOS to handle INT13 requests, this information
    must be constructed artificially instead when booted from EFI.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23773:dd90b59cb11c
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Fri Aug 19 09:54:53 2011 +0100
    x86: trampoline cleanup
    To make future changes less error prone, and to slightly simplify a
    possible future conversion to a relocatable trampoline even for the
    multiboot path (pretty desirable given that we had to change the
    trampoline base a number of times to escape collisions with firmware
    placed data),
    - remove final uses of bootsym_phys() from trampoline.S, allowing the
      symbol to be undefined before including this file (to make sure no
      new references get added)
    - replace two easy to deal with uses of bootsym_phys() in head.S
    - remove an easy to replace reference to BOOT_TRAMPOLINE
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23772:29aeed4979a7
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Fri Aug 19 09:54:26 2011 +0100
    x86: make run-time part of trampoline relocatable
    In order to eliminate an initial hack in the EFI boot code (where
    memory for the trampoline was just "claimed" instead of properly
    allocated), the trampoline code must no longer make assumption on the
    address at which it would be located. For the time being, the fixed
    address is being retained for the traditional multiboot path.
    As an additional benefit (at least from my pov) it allows confining
    the visibility of the BOOT_TRAMPOLINE definition to just the boot
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
changeset:   23771:fc2be6cb89ad
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>
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®.