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] 6532: regressions - trouble: broken/fail

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
Date: Wed, 16 Mar 2011 21:58:04 +0000
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Wed, 16 Mar 2011 14:59:44 -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 6532 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-pv           5 xen-boot                   fail REGR. vs. 6396
 test-amd64-amd64-xl-win       3 host-install(3)              broken
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                 fail REGR. vs. 6396
 test-amd64-xcpkern-i386-rhel6hvm-intel  5 xen-boot         fail REGR. vs. 6396
 test-amd64-xcpkern-i386-win   5 xen-boot                   fail REGR. vs. 6396
 test-i386-i386-pair           3 host-install/src_host(3)     broken
 test-i386-xcpkern-i386-win    5 xen-boot                   fail REGR. vs. 6396

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  8 guest-saverestore            fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-xcpkern-i386-rhel6hvm-amd  8 guest-saverestore      fail never pass
 test-amd64-xcpkern-i386-xl-win 13 guest-stop                   fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c426a7140c99
baseline version:
 xen                  a8fee4ad3ad0

------------------------------------------------------------
People who touched revisions under test:
  Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxxxx>
  Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  Tim Deegan <Tim.Deegan@xxxxxxxxxx>
  Wei Gang <gang.wei@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-i386-xcpkern                                           pass     
 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-xcpkern-i386-xl                                   pass     
 test-i386-xcpkern-i386-xl                                    pass     
 test-amd64-i386-rhel6hvm-amd                                 fail     
 test-amd64-xcpkern-i386-rhel6hvm-amd                         fail     
 test-amd64-i386-xl-credit2                                   pass     
 test-amd64-xcpkern-i386-xl-credit2                           pass     
 test-amd64-i386-rhel6hvm-intel                               fail     
 test-amd64-xcpkern-i386-rhel6hvm-intel                       fail     
 test-amd64-i386-xl-multivcpu                                 pass     
 test-amd64-xcpkern-i386-xl-multivcpu                         pass     
 test-amd64-amd64-pair                                        pass     
 test-amd64-i386-pair                                         pass     
 test-i386-i386-pair                                          broken   
 test-amd64-xcpkern-i386-pair                                 pass     
 test-i386-xcpkern-i386-pair                                  pass     
 test-amd64-amd64-pv                                          fail     
 test-amd64-i386-pv                                           pass     
 test-i386-i386-pv                                            pass     
 test-amd64-xcpkern-i386-pv                                   pass     
 test-i386-xcpkern-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-xcpkern-i386-win                                  fail     
 test-i386-xcpkern-i386-win                                   fail     
 test-amd64-amd64-xl-win                                      broken   
 test-i386-i386-xl-win                                        fail     
 test-amd64-xcpkern-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:   23045:c426a7140c99
tag:         tip
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue Mar 15 18:20:46 2011 +0000
    
    libxl: Make all hidden/static functions take a gc not a ctx
    
    Also ensure that static and hidden functions use the libxl__ prefix
    not just libxl_ (in the case of static functions only when they use a
    libxl prefix to start with).
    
    This follows the policy described in libxl.h "libxl memory
    management".
    
    Based on a manual audit of:
    grep ^static tools/libxl/libxl*.[ch]| grep libxl_ctx
    grep libxl__ tools/libxl/*.h| grep libxl_ctx
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
changeset:   23044:d4ca456c0c25
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue Mar 15 18:19:47 2011 +0000
    
    libxl: do not start a xenpv qemu solely for tap devices if blktap is 
available
    
    qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is
    available but if blktap is available, or for DISK_BACKEND_PHY, we
    don't need a qemu process.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
changeset:   23043:3caed2112c65
user:        Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
date:        Tue Mar 15 10:14:27 2011 +0000
    
    Avoid endless loop for vcpu migration.
    
    Only call SCHED_OP(pick_cpu) if a previously picked cpu is not
    suitable on the current iteration of the retry loop.
    
    Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23042:599ceb5b0a9b
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Tue Mar 15 10:02:36 2011 +0000
    
    x86/HPET: fix oversight in 23033:84bacd800bf8
    
    Clearly for the adjusted BUG_ON()s to not yield false positives
    num_chs_used must be incremented before setting up an IRQ (and
    decremented back when the setup failed).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23041:9f6dec0d25cd
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Mar 14 17:20:11 2011 +0000
    
    _csched_cpu_pick(): simplify sched_smt_power_savings dependent condition
    
    At least to me, using ?: instead of the (a && ...) || (!a && ...)
    construct is far easier to grok with a single look.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23040:77bb4be5c954
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Mar 14 17:19:47 2011 +0000
    
    _csched_cpu_pick(): don't write idle bias more than once
    
    For the bias to be really meaningful, it should be updated only when
    the CPU selected will indeed be returned (and hence used for placing
    the vCPU in question).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23039:c40da47621d8
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Mar 14 17:19:22 2011 +0000
    
    _csched_cpu_pick(): don't return CPUs outside vCPU's affinity mask
    
    This fixes a fairly blatant bug I introduced in c/s 20377:cff23354d026
    - I wonder how this went unnoticed for so long.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23038:39f5947b1576
user:        Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
date:        Mon Mar 14 17:13:15 2011 +0000
    
    Allow tools to map arbitrarily large machphys_mfn_list on 32bit dom0
    
    This permits suspend/resume to work with 32bit dom0/tools when system
    memory extends beyond 160GB (and up to 1TB).
    
    AFAICT the limit to MACH2PHYS_COMPAT_NR_ENTRIES is redundant since
    that refers to a limit in 32bit guest compat mappings under 64bit
    hypervisors, not userspace where there may be gigabytes of useful
    virtual space available for this.
    
    Suggested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
    Signed-off-by: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
    
    
changeset:   23037:a29b35408950
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Mar 14 17:05:21 2011 +0000
    
    x86: fix cpu_sibling_map initialization when topology CPUID leaf is present
    
    c/s 21811:12f0618400de broke this by not properly initializing struct
    cpuinfo_x86's x86_num_siblings member (other than Linux, where this is
    a global variable, it is being maintained per CPU by Xen).
    
    Hyper-threaded CPUs with CPUID leaf 0xb present had therefore all
    cpu_sibling_map-s with just a single bit set, thus improperly feeding
    the scheduler.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23036:9a15ff175e00
user:        Wei Gang <gang.wei@xxxxxxxxx>
date:        Mon Mar 14 17:04:42 2011 +0000
    
    x86: add volatile prefix for cpuid asm clauses
    
    cpuid results are possible to be changed now. For example, changing
    CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change
    XSAVE related cpuid leave return values.
    
    The volatile prefix is required to avoid the second cpuid calls
    following some possible changing operations being optimized in
    incorrect way by compiler.
    
    The sample bug is in xsave_init while debug=3Dn. The second call to
    cpuid_count() may be optimized and lead to a BUG_ON case while compare
    xsave_cntxt_size with ebx.
    
    Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
    
    
changeset:   23035:56dc6032b45f
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Mon Mar 14 17:02:50 2011 +0000
    
    Force out-of-line instances of inline functions into .init.text in 
init-only code
    
    Some compiler versions may choose to not inline certain functions, but
    the check introduced in c/s 23003:768269c43914 wants .text to be
    empty.
    
    Also make sure an eventual error gets properly propagated even on the
    first section of an object (.text typically being the first one), and
    cover a broader set of sections.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23034:c79aae866ad8
user:        Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date:        Mon Mar 14 16:59:49 2011 +0000
    
    x86_64: fix error checking in arch_set_info_guest()
    
    Cannot specify user mode execution without specifying user-mode
    pagetables.
    
    Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   23033:84bacd800bf8
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Mar 12 13:20:51 2011 +0000
    
    x86/HPET: adjust types
    
    'unsigned int' is better suited as an array index on x86-64.
    
    'u32' produces better code than 'unsigned long' on x86-64, so use the
    former for storing 32-bit values read from the hardware.
    
    this_cpu() uses an implicit smp_processor_id(), and hence using
    per_cpu() when the result of smp_processor_id() is already available
    is more efficient.
    
    Fold one case of cpu_isset()+cpu_clear() into cpu_test_and_clear().
    
    Drop the unused return value of evt_do_broadcast().
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
    
    
changeset:   23032:ac572e1df261
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Mar 12 13:20:11 2011 +0000
    
    x86/HPET: use dynamic allocation for hpet_events[]
    
    Typically there are far less than 32 counters available, and hence
    there's no use in wasting the memory on (almost) every system.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
    
    
changeset:   23031:5263151fba9b
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Mar 12 13:19:34 2011 +0000
    
    x86/HPET: cleanup
    
    - separate init and resume code paths (so that the [larger] init parts
      can go init .init.* sections)
    - drop the separate legacy_hpet_event object, as we can easily re-use
      the first slot of hpet_events[] for that purpose (the whole array is
      otherwise unused when the legacy code is being used)
    - use section placement attributes where reasonable
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
    
    
changeset:   23030:87aa1277eae0
user:        Jan Beulich <jbeulich@xxxxxxxxxx>
date:        Sat Mar 12 13:19:02 2011 +0000
    
    x86/HPET: fix initialization order
    
    At least the legacy path can enter its interrupt handler callout while
    initialization is still in progress - that handler checks whether
    ->event_handler is non-NULL, and hence all other initialization must
    happen before setting this field.
    
    Do the same to the MSI initialization just in case (and to keep the
    code in sync).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
    
    
changeset:   23029:a8fee4ad3ad0
user:        Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
date:        Fri Mar 11 18:22:23 2011 +0000
    
    libxl: do not try to use blktap with qdisk
    
    libxl_device_disk_add tries to use blktap when available even for qdisk
    devices, this patch fixes it.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel