[linux-arm-xen test] 58849: regressions - FAIL

[osstest service user <osstest@xenbits.xen.org>]

flight 58849 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58849/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 11 guest-start             fail REGR. vs. 58830

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-sedf     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check        fail  never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass

version targeted for testing:
 linux                64972ceb0b0cafc91a09764bc731e1b7f0503b5c
baseline version:
 linux                9f51b5de8c3fdd01a9d692da5633449cc6936688

------------------------------------------------------------
People who touched revisions under test:
  David S. Miller <davem@davemloft.net>
  Ian Campbell <ian.campbell@citrix.com>
  Luis Henriques <luis.henriques@canonical.com>
  Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------

jobs:
 build-armhf-xsm                                              pass    
 build-armhf                                                  pass    
 build-armhf-libvirt                                          pass    
 build-armhf-pvops                                            pass    
 test-armhf-armhf-xl                                          pass    
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-armhf-armhf-xl-xsm                                      pass    
 test-armhf-armhf-xl-arndale                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               fail    
 test-armhf-armhf-libvirt                                     pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-armhf-armhf-xl-sedf-pin                                 pass    
 test-armhf-armhf-xl-sedf                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 64972ceb0b0cafc91a09764bc731e1b7f0503b5c
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Mon Jun 1 11:30:24 2015 +0100

    xen: netback: read hotplug script once at start of day.
    
    commit 31a418986a5852034d520a5bab546821ff1ccf3d upstream.
    
    When we come to tear things down in netback_remove() and generate the
    uevent it is possible that the xenstore directory has already been
    removed (details below).
    
    In such cases netback_uevent() won't be able to read the hotplug
    script and will write a xenstore error node.
    
    A recent change to the hypervisor exposed this race such that we now
    sometimes lose it (where apparently we didn't ever before).
    
    Instead read the hotplug script configuration during setup and use it
    for the lifetime of the backend device.
    
    The apparently more obvious fix of moving the transition to
    state=Closed in netback_remove() to after the uevent does not work
    because it is possible that we are already in state=Closed (in
    reaction to the guest having disconnected as it shutdown). Being
    already in Closed means the toolstack is at liberty to start tearing
    down the xenstore directories. In principal it might be possible to
    arrange to unregister the device sooner (e.g on transition to Closing)
    such that xenstore would still be there but this state machine is
    fragile and prone to anger...
    
    A modern Xen system only relies on the hotplug uevent for driver
    domains, when the backend is in the same domain as the toolstack it
    will run the necessary setup/teardown directly in the correct sequence
    wrt xenstore changes.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Luis Henriques <luis.henriques@canonical.com>