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

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



flight 7418 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/7418/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-pair         16 guest-start                fail REGR. vs. 7329
 test-amd64-i386-pv            9 guest-start                fail REGR. vs. 7329
 test-amd64-i386-xl-multivcpu  9 guest-start                fail REGR. vs. 7329
 test-amd64-i386-xl            9 guest-start                fail REGR. vs. 7329
 test-i386-i386-pv             9 guest-start                fail REGR. vs. 7329
 test-i386-i386-xl             9 guest-start                fail REGR. vs. 7329

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    8 debian-fixup                 fail pass in 7405

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-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail    like 7318
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail  like 7313
 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-rhel6hvm-intel  8 guest-saverestore    fail never pass
 test-amd64-xcpkern-i386-win  16 leak-check/check             fail   never pass
 test-amd64-xcpkern-i386-xl-win 13 guest-stop                   fail never pass
 test-i386-i386-pair          16 guest-start                  fail    like 7313
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-xcpkern-i386-win   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  dbe9e02a1f75
baseline version:
 xen                  61336bbb0002

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jim Fehlig <jfehlig@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Li, Xin <xin.li@xxxxxxxxx>
  Tim Deegan <Tim.Deegan@xxxxxxxxxx>
  Yang, Wei <wei.y.yang@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                                           fail     
 test-i386-i386-xl                                            fail     
 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                                   fail     
 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                                 fail     
 test-amd64-xcpkern-i386-xl-multivcpu                         pass     
 test-amd64-amd64-pair                                        pass     
 test-amd64-i386-pair                                         fail     
 test-i386-i386-pair                                          fail     
 test-amd64-xcpkern-i386-pair                                 pass     
 test-i386-xcpkern-i386-pair                                  pass     
 test-amd64-amd64-pv                                          pass     
 test-amd64-i386-pv                                           fail     
 test-i386-i386-pv                                            fail     
 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                                      fail     
 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:   23069:dbe9e02a1f75
tag:         tip
user:        Yang, Wei <wei.y.yang@xxxxxxxxx>
date:        Sat May 28 09:22:55 2011 +0100
    
    x86/intel: Fix CPUID leaf 7 detection
    
    Must set subleaf to 0 (input ECX==0).
    
    Signed-off-by: Yang, Wei <wei.y.yang@xxxxxxxxx>
    Signed-off-by: Li, Xin <xin.li@xxxxxxxxx>
    xen-unstable changeset:   23436:f6ce871e5689
    xen-unstable date:        Sat May 28 08:57:12 2011 +0100
    
    
changeset:   23068:3f2f2543e943
user:        Keir Fraser <keir@xxxxxxx>
date:        Sat May 28 09:17:15 2011 +0100
    
    Clean up stdarg handling a little. Fix for NetBSD.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset:   23432:14eb8e1fcd82
    xen-unstable date:        Fri May 27 15:49:24 2011 +0100
    
    
changeset:   23067:f408456e30e8
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Sat May 28 09:16:08 2011 +0100
    
    IOMMU: Fail if intremap is not available and iommu=required/force.
    
    Rather than sprinkling panic()s throughout the setup code hoist the
    check up into common code.
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    xen-unstable changeset:   23402:f979a1a69fe3
    xen-unstable date:        Thu May 26 08:18:44 2011 +0100
    
    
changeset:   23066:d0feff6ff44c
user:        Markus Gross <gross@xxxxxxxxxxxxx>
date:        Sat May 28 09:09:40 2011 +0100
    
    libxc: obtain correct length of p2m during core dumping
    
    while implementing core dumping functionality for the libxl driver
    of libvirt, I discovered an issue with mapping pages of a pv guest.
    
    After dumping the core of a pv guest the domain was not cleared up
    properly and some pages were not unmapped. This issue is similar
    to the one reported here:
    http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01314.html
    
    In xc_domain_dumpcore_via_callback in the file xc_core.c the function
    xc_core_arch_map_p2m is called to map P2M_FL_ENTRIES pages to the
    variable p2m.
    But to unmap the pages later, the dinfo->p2m_size has to be set
    accordingly.
    This was not done, instead a variable named p2m_size was set.
    This way P2M_FL_ENTRIES was always zero and the pages were left
    mapped.
    
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    xen-unstable changeset:   23374:8bd7b5e98f2a
    xen-unstable date:        Tue May 24 15:00:16 2011 +0100
    
    
changeset:   23065:41fcee15368a
user:        Jim Fehlig <jfehlig@xxxxxxxxxx>
date:        Sat May 28 09:08:21 2011 +0100
    
    libxc: after saving, unmap correct amount for live_m2p
    
    With some help from Olaf, I've finally got to the bottom of an issue I
    came across while trying to implement save/restore in the libvirt
    libxenlight driver.  After issuing the save operation, the saved
    domain was not being cleaned up properly and left in this state from
    xl's perspective
    
    xen33:# xl list
    Name                   ID   Mem VCPUs      State   Time(s)
    Domain-0                0  6821     8     r-----     122.5
    (null)                  2     2     2     --pssd      10.8
    
    Checking the libvirtd /proc/$pid/maps I found this
    
    7f3798984000-7f3798b86000 r--s 00002000 00:03 4026532097
    /proc/xen/privcmd
    
    So not all all pages belonging to the domain were unmapped from
    libvirtd.  In tools/libxc/xc_domain_save.c we found that
    P2M_FL_ENTRIES were being mapped but only P2M_FLL_ENTRIES were being
    unmapped.  The attached patch changes the unmapping to use the same
    P2M_FL_ENTRIES macro.  I'm not too familiar with this code though so
    posting here for review.
    
    I suspect this was not noticed before since most (all?) processes
    doing save terminate after the save and are not long-running like
    libvirtd.
    
    Ian Campbell writes:
    > Looks like I introduced this in 18558:ccf0205255e1, sorry!
    >
    > I guess it is also wrong in the error path out of map_and_save_p2m_table
    > and so we also need [another hunk].
    
    This change should be backported to relevant earlier trees. -iwj
    
    From: Jim Fehlig <jfehlig@xxxxxxxxxx>
    From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Cc: Olaf Hering <olaf@xxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    xen-unstable changeset:   23373:171007b4e2c4
    xen-unstable date:        Tue May 24 14:50:00 2011 +0100
    
    
changeset:   23064:61336bbb0002
user:        Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date:        Tue May 24 08:19:39 2011 +0100
    
    drivers/passthrough: fix error paths in pci_add_device*()
    
    When a device can't be allocated to dom0 by the IOMMU, don't leave
    dom0 in the "domain" field.  It causes pci_remove_device()
    to crash trying to remove the dev from the domain's list of devices
    (and was probably the wrong thing to do anyway).
    
    Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
    xen-unstable changeset:   23371:4326bcd88b33
    xen-unstable date:        Mon May 23 18:35:32 2011 +0100
    
    
    drivers/passthrough: Revert 23352:ea48976517af -- incorrect bugfix.
    
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset:   23370:2e6719425265
    xen-unstable date:        Mon May 23 18:35:04 2011 +0100
    
    
(qemu changes not included)

_______________________________________________
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®.