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/
Home Products Support Community News


[Xen-devel] [xen-unstable test] 7315: regressions - FAIL

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [xen-unstable test] 7315: regressions - FAIL
From: xen.org <ian.jackson@xxxxxxxxxxxxx>
Date: Wed, 25 May 2011 06:28:49 +0100
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Tue, 24 May 2011 22:29:56 -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 7315 xen-unstable real [real]

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 7285

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-intel  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-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-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                  2e4d29c1c585
baseline version:
 xen                  37c77bacb52a

People who touched revisions under test:
  Ian Campbell <Ian.Campbell@xxxxxxxxxx>
  Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jim Fehlig <jfehlig@xxxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Liu, Jinsong <jinsong.liu@xxxxxxxxx>
  Shriram Rajagopalan <rshriram@xxxxxxxxx>
  Tim Deegan <Tim.Deegan@xxxxxxxxxx>

 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                                          pass     
 test-amd64-xcpkern-i386-pair                                 pass     
 test-i386-xcpkern-i386-pair                                  pass     
 test-amd64-amd64-pv                                          pass     
 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                                      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

Test harness code can be found at

Not pushing.

changeset:   23381:2e4d29c1c585
tag:         tip
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 16:18:19 2011 +0100
    libxl: don't close file descriptors 4..255 in libxl__exec
    It prevents callers from deliberately passing file descriptors to the child,
    hides any callers who erroneously do so and doesn't deal with all file
    descriptors in any case.
    Rather than remove it all together replace it with some debug code
    which checks for open file handles which do not have either O_CLOEXEC
    or FD_CLOEXEC set. To enable the debug set _LIBXL_DEBUG_EXEC_FDS=1 to
    print any open and non-CLOEXEC non-stdio FDs just before libxl__exec
    actualy calls exec. Set _LIBXL_DEBUG_EXEC_FDS=2 to abort if any of
    these exist.
    On the basis of this debugging fix some leaked filehandles:
      * The read end of the pipe used to wake the parent from the
        intermediate process during libxl__spawn_spawn was leaked into the
        intermediate process.
      * The file descriptor representing the xl lock was not marked
        O_CLOEXEC (the lock itself is already specified to not be
        inherited across a fork).
      * The file descriptors passed to libxl__exec to be dup'd as
        std{in,out,err} were leaked at their original number. They are
        harmless (an attacker can just as easily use fd 0..2) but close
        anyway since it removes a case which a person evaluating open fd's
        needs to consider.
      * libxl_run_bootloader was leaking the xenconsole pty master into
        the bootloader child process.
      * If the bootloader fails to get as far as opening its end of the
        FIFO then we can also hang, check that the process has not exited
        as part of that loop. (we actually block opening the FIFO too so
        this is only a partial fix for the case where the bootlader has
        crashed quickly).
    With these fixes I have tested that device models, bootloaders
    (pygrub) and vncviewers which are spawned via libxl__exec with no
    unexpected file descriptors open, at least in my configuration.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23380:e38f655a7245
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 16:15:53 2011 +0100
    libxl: improve logging on failure to start device model.
    Distinguish between device model dying during startup (libxl__spawn_check
    returns failure) and timing out while waiting for the xenstore node to show 
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23379:b04e57ec4671
user:        Jinsong Liu <jinsong.liu@xxxxxxxxx>
date:        Tue May 24 16:12:25 2011 +0100
    remus: write circumlocution for try..except..finally
      File "/usr/lib64/python2.4/site-packages/xen/remus/save.py", line 169
    SyntaxError: invalid syntax
    This was introduced in 23195:13ec53a59a42
    It is a problem for Python 2.4 and earlier, only.
    So use try...(try...except)...finally as suggested by Ian Campbell.
    Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx>
    Acked-by: Shriram Rajagopalan <rshriram@xxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23378:07f1c287ca5e
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 15:57:24 2011 +0100
    libxl: add statup checks to libxl__wait_for_device_model
    When the device model is starting up push checks for spawn failure down into
    libxl__wait_for_device_model, allowing us to fail more quickly when the 
    model fails to start (e.g. due to a missing library or an early setup error
    In order to allow the select loop in libxl__wait_for_device_model to wake 
    the child dies add pipe between the parent and the intermediate process 
    the intermediate process can use to signal the parent.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23377:7cc5787ee24b
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 15:21:26 2011 +0100
    libxl: pass libxl__spawn_starting to libxl__spawn_spawn.
    Passing a libxl__device_model_starting to a generic function and expecting 
    to scrobble inside for the generic data structure is a strange interface.
    Instead pass in a libxl__spawn_starting and an opaque hook data pointer.
    The for_spawn member of libxl__device_model_starting was annotated with
    "first!", suggesting that someone intended to use pointer casting tricks to
    move between the outer and inner struct. However the field is a pointer not 
    inline struct so this doesn't work (and it isn't used this way anyhow). 
    the comment, and move the field away from the front for good measure.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23376:efb1fa6f82e2
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 15:17:07 2011 +0100
    libxl: remove redundant call to libxl_domain_device_model
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23375:61d0fabf9dd2
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue May 24 15:15:27 2011 +0100
    libxl: check that device model binary is executable.
    This causes us to fail more quickly in more obvious failure case of not
    having the right binary installed.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23374:8bd7b5e98f2a
user:        Markus Gross <gross@xxxxxxxxxxxxx>
date:        Tue May 24 15:00:16 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:
    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 
    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.
    [ This change should be considered for backport to relevant trees. ]
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
changeset:   23373:171007b4e2c4
user:        Jim Fehlig <jfehlig@xxxxxxxxxx>
date:        Tue May 24 14:50:00 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
    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
    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>
changeset:   23372:d74585e5dc9f
user:        Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date:        Tue May 24 09:30:51 2011 +0100
    x86/mm: Fix one more check in the EPT p2m code
    This is one more place that needs to check for 0 entries
    after the AMD p2m-sharing patch made p2m_ram_rw == 0
    Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
changeset:   23371:4326bcd88b33
user:        Tim Deegan <Tim.Deegan@xxxxxxxxxx>
date:        Mon May 23 18:35:32 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>
changeset:   23370:2e6719425265
user:        Keir Fraser <keir@xxxxxxx>
date:        Mon May 23 18:35:04 2011 +0100
    drivers/passthrough: Revert 23352:ea48976517af -- incorrect bugfix.
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
changeset:   23369:37c77bacb52a
user:        Keir Fraser <keir@xxxxxxx>
date:        Mon May 23 17:38:28 2011 +0100
    Fix Config.mk's cc-option for -Wno-* options.
    These disable-warning options are handled specially by GCC:
     (a) they are ignored unless the compiler emits a warning; and
     (b) even then they produce a warning rather than an error
    To handle this, modify the test invocation of GCC to compile a
    fragment of code that will always provoke a warning (integer assigned
    to pointer). This works around (a) above.
    Then, we grep the compiler's stdout/stderr for the option-under-test,
    the presence of which would indicate an "unrecognized command-line
    option" warning/error. This works around (b) above, letting us
    distinguish between the "integer assigned to pointer" and
    "unrecognized command-line option" warnings.
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
(qemu changes not included)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [xen-unstable test] 7315: regressions - FAIL, xen . org <=