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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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).

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