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@lists.xen.org
https://lists.xen.org/xen-devel
