|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)
On Wed, 17 Jun 2015, Ian Jackson wrote:
> Jan Beulich writes ("stable trees (was: [xen-4.2-testing test] 58584:
> regressions)"):
> > Which leaves several options:
> > - the problem was always there, but hidden by some factor in the
> > old osstest instance,
>
> I think this is most likely. The old system had much older hosts.
>
> I think this is a race that we now happen to lose most of the time.
>
> > - this is an infrastructure problem in the new osstest instance
> > (after all what makes the tests fail is a ping timing out, which can
> > have a variety of reasons),
>
> I think this is very unlikely. When we were investigating the FreeBSD
> migration failure, I looked at this possibility in some depth. I ran
> a number of long-term ping tests between various infrastructure
> machines and test boxes and saw nothing untoward (for example, no
> unexpected packet loss). (In the end the problem turned out to be a
> race bug in the FreeBSD netfront, which would try to send the
> gratuitous ARP before the backend was up.)
>
> > - this is a build or runtime problem due to software differences
> > between the old and new instances (no idea whether exact same
> > package versions were used at the time of the switchover),
>
> All the builds are done on hosts frequently reinstalled from Debian
> upstream. The compiler would change if Debian released an updated
> package but not otherwise. So the old and new build environments
> would be very close to identical, apart from the hardware, hostnames,
> etc.
>
> > One aspect making me indeed consider the build (or less likely
> > runtime) aspect is that we're seeing the frequent migration failures
> > in the stable trees only - other than unstable they're all getting built
> > with debug=n.
>
> Races frequently come and go with that kind of change.
>
> > While I agree that it wouldn't be nice to release 4.5.1 with these
> > failures not understood, the current situation (with no-one having
> > a real idea of what's going on, and apparently also no-one really
> > trying to debug the issue - it being migration _and_ [apparently]
> > qemuu specific I don't really feel qualified myself, leaving aside any
> > time constraints, which certainly also apply to others) will lead to
> > an indefinite stall on both this tree and the 4.4 one (4.4.3 would
> > be due in about a month, i.e. normally I would send out a call for
> > backport requests around now).
>
> I think going ahead with 4.5.1 anyway would be a reasonable choice.
>
> Stefano ?
I agree
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |