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

[Xen-devel] [xen-unstable test] 8699: trouble: broken/fail/pass



flight 8699 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8699/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-pair          3 host-install/src_host(3)     broken
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)              broken
 test-amd64-i386-win-vcpus1    3 host-install(3)              broken
 test-amd64-i386-win           3 host-install(3)              broken
 test-i386-i386-xl-win         3 host-install(3)              broken
 test-i386-i386-win            3 host-install(3)              broken
 test-amd64-amd64-win          3 host-install(3)              broken

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-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  0ddb4481f883
baseline version:
 xen                  fc2be6cb89ad

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
------------------------------------------------------------

jobs:
 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                                         broken  
 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                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        broken  


------------------------------------------------------------
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:   23776:0ddb4481f883
tag:         tip
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)
     .ctors         0x0000000000097004       0x10
                    
/home/jeremy/hg/xen/unstable/stubdom/mini-os-x86_32-grub/mini-os.o
                    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
    code.
    
    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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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