Re: [Xen-devel] [linux-arm-xen test] 107164: regressions - FAIL

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 4 Apr 2017, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [linux-arm-xen test] 107164: 
> regressions - FAIL"):
> > On 04/04/2017 04:14 AM, osstest service owner wrote:
> > > flight 107164 linux-arm-xen real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/107164/
> ...
> > >  test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 
> > > 62674
> > >  test-armhf-armhf-libvirt     13 saverestore-support-check fail REGR. vs. 
> > > 62674
> > 
> > Looking at the result, it fails because of save/restore that has never 
> > been supported on ARM.
> 
> Indeed.  I think the pass in 62674 was spurious.
> 
> Looking at the git logs between the version of osstest used in flight
> 62674, and current production, there were a bunch of fixes to the
> migration support check.  Notably
>   6a9b295891f8e1a952936ce7f7e0ebae56e13797
>   libvirt: Do not attempt save/restore when migration not advertised
> which says "Currently, osstest wrongly thinks that ARM can do
> save/restore, ..."
> 
> The bisector had a go but failed to repro the basis pass, instead
> getting the expected failure:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107171/test-armhf-armhf-libvirt-xsm/13.ts-saverestore-support-check.log
> The bisector runs with the previous versions of everything except
> osstest itself, so this is consistent.
> 
> Also, I picked a sample job run on an arndale to check that it still
> gets the Xen serial log:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107164/test-armhf-armhf-libvirt/info.html
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107164/test-armhf-armhf-libvirt/serial-arndale-metrocentre.log
> 
> > Ian, would it be possible to force push linux-arm-xen?
> 
> So, indeed, 
> 
> > > version targeted for testing:
> > >  linux                6878b2fa7229c9208a02d45f280c71389cba0617
> 
> I have force pushed that version.
> 
> 
> To summarise our irc conversation about serial host properties on the
> arndale:
> 
> Our plan was:
> 
> 1. Push linux-arm-xen with a change to the Linux DT to support
> "dtuart=serial2".  (Now done.)
> 
> 2. When that passes the push gate (now done) and is being used
> everywhere (not quite yet), we change the XenDTUARTPath setting for
> the arndales to "serial2" from "/serial@12C20000".
> 
> 3. After that, use "git merge -s ours" to create a commit on
> linux-arm-xen which is a fast-forward update, but which is actually
> identical to a suitable linux 4.x (probably linux 4.9 for now, because
> that's a stable branch upstream).

I readied a 4.9.y based fast-forwarding linux-arm-xen branch ready to be
pushed. Just let me know when appropriate.


> 4. Any resulting regressions will have to be fixed up, presumably in
> Xen staging/master or the appropriate linux 4.x.y stable upstream
> branch, and then:
> 
> 5. When the 4.x-ish linux-arm-xen (ie, the version which is identical
> to some upstream 4.x but is fast forward from old linux-arm-xen
> revisions) passes the push gate, we will manually rewind both the
> linux-arm-xen input and output push gate branches to the corresponding
> upstream 4.x revision - ie, no code change, but dropping the history
> noise.
> 
> 
> Because the Linux ARM commit to use is frozen at flight start, but
> host properties settings are not, we need to wait for existing flights
> using old linux-arm-xen to finish before changing the host setting.
> 
> Thanks,
> Ian.
> 

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