WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [xen-unstable test] 8284: trouble: broken/fail/pass
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
Date: Tue, 26 Jul 2011 15:46:58 +0100
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Tue, 26 Jul 2011 07:47:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
flight 8284 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8284/

Failures and problems with tests :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)              broken
 test-amd64-amd64-win          3 host-install(3)              broken
 test-amd64-amd64-pv           3 host-install(3)              broken
 test-amd64-i386-pv            3 host-install(3)              broken
 test-i386-i386-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-i386-i386-xl             5 xen-boot                     fail    like 8240
 test-i386-i386-pv             5 xen-boot                     fail    like 8256
 test-amd64-i386-xl-multivcpu  5 xen-boot                     fail    like 8256
 test-amd64-amd64-xl           5 xen-boot                     fail    like 8249
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                     fail    like 8236
 test-amd64-i386-win-vcpus1    5 xen-boot                     fail    like 8256
 test-amd64-i386-xl            5 xen-boot                     fail    like 8244
 test-i386-i386-pair           7 xen-boot/src_host            fail    like 8256
 test-i386-i386-pair           8 xen-boot/dst_host            fail    like 8256
 test-amd64-amd64-xl-win       5 xen-boot                     fail    like 8249
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win         5 xen-boot                     fail    like 8256
 test-amd64-i386-win          16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  e8d1c8f074ba
baseline version:
 xen                  42edf1481c57

------------------------------------------------------------
People who touched revisions under test:
  Bei Guan <gbtju85@xxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Liu, Jinsong <jinsong.liu@xxxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
  Tim Deegan <Tim.Deegan@xxxxxxxxxx>
------------------------------------------------------------

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                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           broken  
 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
    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:   23749:e8d1c8f074ba
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Jul 25 16:43:26 2011 +0100
    
    x86-64/MMCFG: pass down firmware (ACPI) reservation status of used memory 
space
    
    Reserving the MMCFG address range(s) in E820 is specified to only be
    optional for the firmware to do. The requirement is to have them
    reserved in ACPI resources. Those, however, aren't directly visible to
    Xen as they require the ACPI interpreter to be active. Thus, if a
    range isn't reserved in E820, we should not completely disable use of
    MMCFG on the respective bus range, but rather keep it disabled until
    Dom0 can pass down information on the ACPI reservation status (though
    a new physdevop hypercall).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23748:e1717d180897
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Jul 25 16:42:53 2011 +0100
    
    x86-64/MMCFG: finally make Fam10 enabling work
    
    Forcibly enabling the MMCFG space on AMD Fam10 CPUs cannot be expected
    to work since with the firmware not being aware of the address range
    used it cannot possibly reserve the space in E820 or ACPI resources.
    Hence we need to manually insert the range into the E820 table, and
    enable the range only when the insertion actually works without
    conflict.
    
    Further, the actual enabling of the space is done from identify_cpu(),
    which means that acpi_mmcfg_init() muts be called after that function
    (and hance should not be called from acpi_boot_init()). Otherwise,
    Dom0 would be able to use MMCFG, but Xen wouldn't.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23747:b07b6fa76656
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Jul 25 16:42:19 2011 +0100
    
    x86-64/MMCFG: correct base address computation for regions not starting at 
bus 0
    
    As per the specification, the base address reported by ACPI is the one
    that would be used if the region started at bus 0. Hence the
    start_bus_number offset needs to be added not only to the virtual
    address, but also the physical one when establishing the mapping, and
    it then needs to be subtracted when obtaining the virtual address for
    doing accesses.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23746:aa54b8175954
user:        Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date:        Mon Jul 25 16:41:33 2011 +0100
    
    VT-d: always clean up dpci timers.
    Message-ID: <20110718163848.GD18276@xxxxxxxxxxxxxxxxxxxxxxx>
    MIME-Version: 1.0
    Content-Type: text/plain; charset="iso-8859-1"
    Content-Disposition: inline
    User-Agent: Mutt/1.5.21 (2010-09-15)
    
    If a VM has all its PCI devices deassigned, need_iommu(d) becomes
    false but it might still have DPCI EOI timers that were init_timer()d
    but not yet kill_timer()d.  That causes xen to crash later because the
    linked list of inactive timers gets corrupted, e.g.:
    
    (XEN) Xen call trace:
    (XEN)    [<ffff82c480126256>] set_timer+0x1c2/0x24f
    (XEN)    [<ffff82c48011fbf8>] schedule+0x129/0x5dd
    (XEN)    [<ffff82c480122c1e>] __do_softirq+0x7e/0x89
    (XEN)    [<ffff82c480122c9d>] do_softirq+0x26/0x28
    (XEN)    [<ffff82c480153c85>] idle_loop+0x5a/0x5c
    (XEN)
    (XEN)
    (XEN) ****************************************
    (XEN) Panic on CPU 0:
    (XEN) Assertion 'entry->next->prev == entry' failed at
    /local/scratch/tdeegan/xen-unstable.hg/xen/include:172
    (XEN) ****************************************
    
    The following patch makes sure that the domain destruction path always
    clears up the DPCI state even if !needs_iommu(d).
    
    Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
    
    
changeset:   23745:9dbbf1631193
user:        Keir Fraser <keir@xxxxxxx>
date:        Mon Jul 25 14:21:13 2011 +0100
    
    hvmloader: Allow default response to be specified to xenstore_read().
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23744:3244ff483d61
user:        Keir Fraser <keir@xxxxxxx>
date:        Mon Jul 25 14:09:41 2011 +0100
    
    hvmloader: Formatting cleanups.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23743:360b31a5263c
user:        Keir Fraser <keir@xxxxxxx>
date:        Mon Jul 25 13:57:49 2011 +0100
    
    hvmloader: Replace bios_relocate hook with bios_load hook
    
    Used by OVMF BIOS handler.
    
    Signed-off-by: Bei Guan <gbtju85@xxxxxxxxx>
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23742:50ddc200a60c
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Jul 25 13:48:08 2011 +0100
    
    fix regression from c/s 23735:537918f518ee
    
    This was checking presence of the wrong (old) ELF note. I don't really
    understand how this failed consistently only for one of the xen-boot
    tests...
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23741:d8725d9fb865
user:        Keir Fraser <keir@xxxxxxx>
date:        Sat Jul 23 09:57:04 2011 +0100
    
    hvmloader: Declare get_hvm_info_table/get_shared_info as const funcs.
    
    The compiler can perform CSE on their call sites.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23740:5f7dc61e166b
user:        Keir Fraser <keir@xxxxxxx>
date:        Sat Jul 23 09:56:13 2011 +0100
    
    hvmloader: Remove bogus and unused RESERVED_MEMSIZE decl.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23739:815ef5cf0261
user:        Keir Fraser <keir@xxxxxxx>
date:        Sat Jul 23 09:43:47 2011 +0100
    
    hvmloader: New functions mem_hole_alloc() and mem_hole_populate_ram().
    
    These can be used by BIOS-specific handlers to set up memory regions
    as required by their firmware payload.
    
    Use mem_hole_alloc() to allocate properly reserved space for the
    shared-info-page mapping. The old location conflicts with space
    required for the OVMF BIOS (support for which is work in progress).
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23738:88847c424eec
user:        Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
date:        Sat Jul 23 08:58:37 2011 +0100
    
    xend: remove PCI device listing from NetBSD, since it's Linux
    specific code.
    
    Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
    
    
changeset:   23737:3d18ff6589e3
user:        Liu, Jinsong <jinsong.liu@xxxxxxxxx>
date:        Sat Jul 23 08:56:58 2011 +0100
    
    x86, mce: Dump mce log by ERST when mc panic
    
    We have implemented basic ERST logic before. Now linux3.0 as dom0 has
    included APEI logic. Hence it's time to add mce apei interface and
    enable APEI ERST feature.
    With it, it can save mce log by ERST method when mc panic.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
    
    
changeset:   23736:31683aa4bfb3
user:        Liu, Jinsong <jinsong.liu@xxxxxxxxx>
date:        Sat Jul 23 08:55:59 2011 +0100
    
    acpi: Add support for old and new bios erst, enable mce_apei logic
    
    When testing, we found different bios has different understanding
    about APEI ERST table header, depending on whether it count ACPI
    standard header or not.
    This patch add support for both bios version, and enable mce_apei.
    
    Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
    
    
changeset:   23735:537918f518ee
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Jul 23 08:49:15 2011 +0100
    
    add privileged (dom0) kernel feature indication
    
    With our switching away from supporting 32-bit Dom0 operation, users
    complained that attempts (perhaps due to lack of knowledge of that
    change) to boot the no longer privileged kernel in Dom0 resulted in
    apparently silent failure. To make the mismatch explicit and visible,
    add dom0 feature flag that the kernel can set to indicate operation as
    dom0 is supported.
    
    Due to the way elf_xen_parse_features() worked up to now (getting
    fixed here), adding features indications to the old, string based ELF
    note would make the respective kernel unusable on older hypervisors.
    For that reason, a new ELF Note is being introduced that allows
    specifying supported features as a bit array instead (with features
    unknown to the hypervisor simply ignored, as now also done by
    elf_xen_parse_features(), whereas here unknown kernel-required
    features still keep the kernel [and hence VM] from booting).
    
    Introduce and use elf_note_numeric_array() to be forward
    compatible (or else an old hypervisor wouldn't be able to parse kernel
    specified features occupying more than 64 bits - thanks, Ian!).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23734:42edf1481c57
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Fri Jul 22 08:55:19 2011 +0100
    
    build: remove $(DESTDIR) from buildmakevars2file paths
    
    23721:0ccb94d533d6 added this by mistake.
    
    Signed-off-by: Ian Campbell <ian.campbell@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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [xen-unstable test] 8284: trouble: broken/fail/pass, xen . org <=