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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-saverestore.2 fail REGR. vs. 
19838

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           3 host-install(3)              broken never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass

version targeted for testing:
 xen                  4deea8515b1caba8803816399068f2a75d65f8ad
baseline version:
 xen                  1aac966e24e92d664089cfa075f21bbb570a7d58

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  Olaf Hering <olaf@xxxxxxxxx>
  Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
  Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 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                                          broken  
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 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.

------------------------------------------------------------
commit 4deea8515b1caba8803816399068f2a75d65f8ad
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Fri Sep 27 10:25:08 2013 +0200

    x86/microcode: Check whether the microcode is correct
    
    We do the microcode code update in two steps - the presmp:
    'microcode_presmp_init' and when CPUs are brought up: 'microcode_init'.
    The earlier performs the microcode update on the BSP - but
    unfortunately it does not check whether the update failed. Which means
    that we might try later to update a incorrect payload on the rest of
    CPUs.
    
    This patch handles this odd situation.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>

commit 155587481e392e4261038364e2761aab27f597ed
Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date:   Fri Sep 27 10:22:55 2013 +0200

    x86/microcode: Scan the initramfs payload for microcode blob
    
    The Linux kernel is able to update the microcode during early bootup
    via inspection of the initramfs blob to see if there is an cpio image
    with certain microcode files. Linux is able to function with two (or
    more) cpio archives in the initrd b/c it unpacks all of the cpio
    archives.
    
    The format of the early initramfs is nicely documented in Linux's
    Documentation/x86/early-microcode.txt:
    
    Early load microcode
    ====================
    By Fenghua Yu <fenghua.yu@xxxxxxxxx>
    
    Kernel can update microcode in early phase of boot time. Loading microcode 
early
    can fix CPU issues before they are observed during kernel boot time.
    
    Microcode is stored in an initrd file. The microcode is read from the initrd
    file and loaded to CPUs during boot time.
    
    The format of the combined initrd image is microcode in cpio format 
followed by
    the initrd image (maybe compressed). Kernel parses the combined initrd image
    during boot time. The microcode file in cpio name space is:
    kernel/x86/microcode/GenuineIntel.bin
    
    During BSP boot (before SMP starts), if the kernel finds the microcode file 
in
    the initrd file, it parses the microcode and saves matching microcode in 
memory.
    If matching microcode is found, it will be uploaded in BSP and later on in 
all
    APs.
    
    The cached microcode patch is applied when CPUs resume from a sleep state.
    
    There are two legacy user space interfaces to load microcode, either through
    /dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
    in sysfs.
    
    In addition to these two legacy methods, the early loading method described
    here is the third method with which microcode can be uploaded to a system's
    CPUs.
    
    The following example script shows how to generate a new combined initrd 
file in
    /boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
    original initrd image /boot/initrd-3.5.0.img.
    
    mkdir initrd
    cd initrd
    mkdir kernel
    mkdir kernel/x86
    mkdir kernel/x86/microcode
    cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
    find .|cpio -oc >../ucode.cpio
    cd ..
    cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
    
    As such this code inspects the initrd to see if the microcode
    signatures are present and if so updates the hypervisor.
    
    The option to turn this scan on/off is gated by the 'ucode'
    parameter. The options are now:
     'scan'      Scan for the microcode in any multiboot payload.
     <index>     Attempt to load microcode blob (not the cpio archive
                 format) from the multiboot payload number.
    
    This option alters slightly the 'ucode' parameter by only allowing
    either parameter:
      ucode=[<index>|scan]
    
    Implementation wise the ucode_blob is defined as __initdata.
    That is OK from the viewpoint of suspend/resume as the the underlaying
    architecture microcode (microcode_intel or microcode_amd) end up saving
    the blob in 'struct ucode_cpu_info' which is a per-cpu data
    structure (see ucode_cpu_info). They end up saving it when doing the
    pre-SMP (for CPU0) and SMP (for the rest) microcode loading.
    
    Naturally if one does a hypercall to update the microcode and it is
    newer, then the old per-cpu data is replaced.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>

commit 0dcfb88fb838ad6f8558f2952feb2f09dc34470f
Author: Olaf Hering <olaf@xxxxxxxxx>
Date:   Fri Sep 27 10:18:03 2013 +0200

    unmodified_drivers: enable build of usbfront driver
    
    Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>

commit 62466514cc419152fa2f33dc9aa986d0a2fc519a
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Sep 27 10:15:28 2013 +0200

    hvmloader/smbios: Change strncpy to memcpy for anchor strings
    
    Coverity complains about the use of strncpy() to completely fill the anchor
    strings, resulting in an unterminated string.
    
    Although the strncpy result is correct, the anchor strings are not strings 
in
    the C sense, and use of memcpy is the prevaling style elsewhere in hvmloader
    anyway.
    
    While tidying up the style in this function, also remove some trailing
    whitespace and gratuitous cast.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>

commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
Author: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
Date:   Fri Sep 27 10:11:49 2013 +0200

    AMD IOMMU: fix Dom0 device setup failure for host bridges
    
    The host bridge device (i.e. 0x18 for AMD) does not require IOMMU, and
    therefore is not included in the IVRS. The current logic tries to map
    all PCI devices to an IOMMU. In this case, "xl dmesg" shows the
    following message on AMD sytem.
    
    (XEN) setup 0000:00:18.0 for d0 failed (-19)
    (XEN) setup 0000:00:18.1 for d0 failed (-19)
    (XEN) setup 0000:00:18.2 for d0 failed (-19)
    (XEN) setup 0000:00:18.3 for d0 failed (-19)
    (XEN) setup 0000:00:18.4 for d0 failed (-19)
    (XEN) setup 0000:00:18.5 for d0 failed (-19)
    
    This patch adds a new device type (i.e. DEV_TYPE_PCI_HOST_BRIDGE) which
    corresponds to PCI class code 0x06 and sub-class 0x00. Then, it uses
    this new type to filter when trying to map device to IOMMU.
    
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
    Reported-by: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
    
    On VT-d refuse (un)mapping host bridges for other than the hardware
    domain.
    
    Coding style cleanup.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
    Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
(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®.