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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-11-30 at 06:12 +0000, xen.org wrote:
> flight 14495 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14495/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qemut-win7-amd64 12 guest-localmigrate/x10 fail REGR. vs. 
> 14483

The logs for this look just like the previous pass, which does include
on each iteration:
                                                                             
        libxl: error: libxl_blktap2.c:80:libxl__device_destroy_tapdisk: Failed 
to destroy tap device id 4851 minor 2: Input/output error
        libxl: error: libxl.c:1467:devices_destroy_cb: libxl__devices_destroy 
failed for 8
        
But that's there before so its something to think about but not the
cause of the failure.

The end of the log is:
        xc: Saving memory: iter 29 (last sent 65 skipped 0): 1048575/1048575  
100%
        migration target: Transfer complete, requesting permission to start 
domain.
        migration sender: Target has acknowledged transfer.
        migration sender: Giving target permission to start.
        migration target: Got permission, starting domain.
        migration target: Domain started successsfully.
        migration sender: Target reports successful startup.
        2012-11-30 01:39:58 Z command timed out [400]: ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_14495.test-amd64-i386-xl-qemut-win7-amd64 
root@xxxxxxxxxxxxx xl migrate win.guest.osstest localhost
        status (timed out) at Osstest.pm line 598.
        + rc=4

(nb: "successsfully" => s/sss/ss/).

Otherwise the xl and qemu logs look fine, the host dmesg is
uninteresting and the guest screenshot looks healthy.

Maybe we've just regressed in terms of the time taken for the
migrations? The changelog is 
    xl: xl.conf(5): correct advice re autoballooning vs. dom0_mem.
    xl: Suppress spurious warning message for cpupool-list
    x86/time: fix scale_delta() inline assembly

None of which seem especially smoking gun shaped. Perhaps just natural
jitter in the time taken (perhaps we hits Windows' daily "cronjob"
run?). Possibly best to wait for another attempt.

Ian.


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