Re: [xen-4.12-testing test] 161776: regressions - FAIL

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.05.2021 18:27, Ian Jackson wrote:
> osstest service owner writes ("[xen-4.12-testing test] 161776: regressions - 
> FAIL"):
>> flight 161776 xen-4.12-testing real [real]
>> flight 161806 xen-4.12-testing real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/161776/
>> http://logs.test-lab.xenproject.org/osstest/logs/161806/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-xl-qcow2    19 guest-localmigrate/x10   fail REGR. vs. 
>> 159418
> 
> This has been failing for 48 days.
> 
>   
> http://logs.test-lab.xenproject.org/osstest/logs/161776/test-amd64-amd64-xl-qcow2/19.ts-guest-localmigrate.log
> 
> shows this:
> 
>   libxl: error: libxl_dom_suspend.c:377:suspend_common_wait_guest_timeout: 
> Domain
> 6:guest did not suspend, timed out
> 
> as the first thing that goes wrong.  This is after the guest has
> acknowledged the suspend request.
> 
> osstest tried to bisect it but was not able to reproduce the basis
> pass.  That means either that we got (un)lucky with the basis pass, or
> that something not version-controlled by osstest is responsible.  In
> this case I think the dom0 and domU kernels, as well as the usual
> pieces, are all properly version controlled by osstest.  The non-Xen
> userland tools are not but I doubt they are the cause.
> 
> So I think this is not a real regression.  In lieu of a fix, I propose
> to force push 5984905b2638df87a0262d1ee91f0a6e14a86df6 to stable-4.12.

I did consider this as an option, but I don't think it's this simple.
Neither 4.11 and older nor 4.13 and newer exhibit such behavior. In
fact in 4.12 we appear to see pushes blocked now because there was a
success of this test once, in flight 159418. So while this may not
be a regression within 4.12 (and hence a force push may still be an
appropriate step), there is something wrong there with 4.12, I would
say. It being out of (general) support may of course mean we want to
leave it at that. Better, for the remaining time the branch is in
security-only maintenance state, would of course be to identify the
(presumably) missing backport ... Of course that's easy to say for
me, because I don't think I would realistically be the one to
undertake such an exercise.

Jan