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

[Xen-devel] [xen-4.1-testing test] 18158: regressions - FAIL

flight 18158 xen-4.1-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 18141

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xend-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-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  8b94e436ed3f83e899f5b0cc403461f95750964b
baseline version:
 xen                  ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978

People who touched revisions under test:
  Aravindh Puthiyaparambil <aravindp@xxxxxxxxx>
  Christoph Egger <chegger@xxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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                                 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-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-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-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-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

Test harness code can be found at

Not pushing.

commit 8b94e436ed3f83e899f5b0cc403461f95750964b
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Mon Jun 17 11:12:41 2013 +0200

    x86/vtsc: update vcpu_time in hvm_set_guest_time
    When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset,
    which is used in the vcpu time structure to calculate the
    tsc_timestamp, so after updating stime_offset we need to propagate the
    change to vcpu_time in order for the guest to get the right time if
    using the PV clock.
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    master commit: 32c864a35ece2c24a336d183869a546798a4b241
    master date: 2013-06-05 10:03:08 +0200

commit 455a677fbfbfca0dcb985f0ae485437483787347
Author: Aravindh Puthiyaparambil <aravindp@xxxxxxxxx>
Date:   Mon Jun 17 11:12:06 2013 +0200

    x86/MCE: disable if MCE banks are not present
    When booting Xen on VMware ESX 5.1 and Workstation 9, you hit a GPF
    during MCE initialization. The culprit is line 631 in
                    bitmap_copy(mb->bank_map, mca_allbanks->bank_map, 
    What is happening is that in mca_cap_init(), nr_mce_banks is being set
    to 0. This causes the allocation of bank_map to be set to
    ZERO_BLOCK_PTR which is the return value for zero-size allocation by
    xzalloc_array()/_xmalloc(). This results in the bitmap_copy() to fail
    disastrously. The following patch fixes this issue.
    Signed-off-by: Aravindh Puthiyaparambil <aravindp@xxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Christoph Egger <chegger@xxxxxxxxx>
    master commit: 5cffb77c4072fa5b46700a2dbb3e46c5a54eba6d
    master date: 2013-06-03 15:42:46 +0200

commit df751b6da15afff1f87a68f63013dd96e9563047
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Jun 17 11:09:09 2013 +0200

    x86: fix ordering of operations in destroy_irq()
    The fix for XSA-36, switching the default of vector map management to
    be per-device, exposed more readily a problem with the cleanup of these
    vector maps: dynamic_irq_cleanup() clearing desc->arch.used_vectors
    keeps the subsequently invoked clear_irq_vector() from clearing the
    bits for both the in-use and a possibly still outstanding old vector.
    Fix this by folding dynamic_irq_cleanup() into destroy_irq(), which was
    its only caller, deferring the clearing of the vector map pointer until
    after clear_irq_vector().
    Once at it, also defer resetting of desc->handler until after the loop
    around smp_mb() checking for IRQ_INPROGRESS to be clear, fixing a
    (mostly theoretical) issue with the intercation with do_IRQ(): If we
    don't defer the pointer reset, do_IRQ() could, for non-guest IRQs, call
    ->ack() and ->end() with different ->handler pointers, potentially
    leading to an IRQ remaining un-acked. The issue is mostly theoretical
    because non-guest IRQs are subject to destroy_irq() only on (boot time)
    error paths.
    As to the changed locking: Invoking clear_irq_vector() with desc->lock
    held is okay because vector_lock already nests inside desc->lock (proven
    by set_desc_affinity(), which takes vector_lock and gets called from
    various desc->handler->ack implementations, getting invoked with
    desc->lock held).
    Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    master commit: 43427e65ccfea0c6dc0232f358287e6cc616b507
    master date: 2013-05-31 08:35:22 +0200
(qemu changes not included)

Xen-devel mailing list



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