[Xen-devel] [xen-4.2-testing test] 17624: regressions - FAIL

[xen.org <ian.jackson@xxxxxxxxxxxxx>]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 17611

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install          fail like 17601

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-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass

version targeted for testing:
 xen                  e5b9f23485aa3709bec753badbcb989fde390925
baseline version:
 xen                  0984c2b63a7c3e9dfa770b29dac51a5124aecaab

------------------------------------------------------------
People who touched revisions under test:
  Dr. Greg Wettstein <greg@xxxxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 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
    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 e5b9f23485aa3709bec753badbcb989fde390925
Author: Dr. Greg Wettstein <greg@xxxxxxxxxxxxxxxxx>
Date:   Tue Mar 19 07:26:33 2013 +0000

    tools: Retry blktap2 tapdisk message on interrupt.
    
    Re-start blktap2 IPC select call on interrupt.
    
    We hunted this miserable bug for a long time.
    
    The teardown of a blktap2 tapdisk instance is being carried out
    inconsistently up to and including the 4.2.1 release.  The
    problem appears to be a classic 'Heisenbug' which disappears if a
    single function call is added to the tapdisk shutdown path.  It
    is likely this bug has been in existence for the life of the
    blktap2 code.
    
    Control messages to manipulate a tapdisk instance are sent over a
    UNIX domain socket.  A select call is used on both the read and
    write paths to wait on I/O and to set a timeout for the
    transmission and reception of the control plane messages.
    
    The existing code fails receipt or transmission of the control message
    on any type of error return from the select call.  The xl control
    process receives an interrupt while waiting in the select call which
    in turn causes an error return with SIGINT as the return code.
    
    This prematurely terminates the teardown of the tapdisk instance
    leaving it in various states of shutdown.  Since multiple messages
    are needed to implement a full teardown the tapdisk instance can be
    left in various states ranging from fully connected to only the minor
    being left allocated.
    
    The fix is straight forward.  Check the return code from the
    select call and re-try read or write of the control message if
    errno is sent to EINTR.  The problem manifests itself in the read
    path but there appears to be little reason to not add the fix to
    the write path as well.  Both paths appear to be cut-and-paste
    copies of each other.
    
    Signed-off-by: Dr. Greg Wettstein <greg@xxxxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    (cherry picked from commit 6cffb2b469a55032a2900ccb8776c0082f346758)

commit c70ce4614ea99bc31450141359ec6c5c53a9f7b2
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Tue Apr 9 15:44:07 2013 +0100

    libxl: run libxl__arch_domain_create() much earlier.
    
    Among other things, arch_domain_create() sets the shadow(/hap/p2m)
    memory allocation, which must happen after vcpus are assigned (or the
    shadow op will fail) but before memory is allocated (or we might run
    out of p2m memory).
    
    libxl__build_pre(), which already sets similar things like maxmem,
    semes like a reasonable spot for it.  That needed a bit of plumbing to
    get the right datastructure from the caller.
    
    As a side-effect, the return code from libxl__arch_domain_create() is
    no longer ignored.
    
    This bug was analysed in:
        From: "Jan Beulich" <JBeulich@xxxxxxxx>
        "Re: [Xen-devel] [xen-unstable test] 16788: regressions - FAIL"
        Date: Mon, 04 Mar 2013 16:34:53 +0000
        http://lists.xen.org/archives/html/xen-devel/2013-03/msg00191.html
    
    Reported-by: Jan Beulich <JBeulich@xxxxxxxx>
    Signed-off-by: Tim Deegan <tim@xxxxxxx>
    Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
    Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
    
    (Cherry-picked from 650354dbc2626b643c12873275ca67782f1382c8.)
    
    Conflicts:
        tools/libxl/libxl_dom.c
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel