[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 56759: regressions - FAIL

On Fri, 2015-05-29 at 10:56 +0100, Andrew Cooper wrote:
> On 28/05/15 11:10, Jan Beulich wrote:
> >>>> On 28.05.15 at 11:26, <ian.campbell@xxxxxxxxxx> wrote:
> >> On Thu, 2015-05-28 at 09:50 +0100, Jan Beulich wrote:
> >>>>>> On 27.05.15 at 18:04, <ian.campbell@xxxxxxxxxx> wrote:
> >>>> On Tue, 2015-05-26 at 14:29 +0100, Ian Campbell wrote:
> >>>>> I've now managed to reproduce using the arndale on my desk.
> >>>> ... and now I've confirmed that reverting the spin lock change causes
> >>>> the issue to not happen any more.
> >>> Considering that this issue has prevented a push for almost
> >>> two weeks, I think we ought to consider reverting the two
> >>> offending commits until the problem got sorted out.
> >> I think that would probably be wise. I'll try and figure out exactly
> >> what is going on and propose some patches ASAP.
> > Now done and pushed.
> Wait what?  This failure is not related to spinlocks; It is a networking
> behavioural bug (hardware specific, even) which has been uncovered,
> showing that there is a preexisting race condition.

That's the current _hypothesis_, but it hasn't been confirmed what is
actually happening here.

So far doing the apparently obvious fix in netback (moving the state
change to closed until after the uevent is generated) doesn't seem to
have fixed the issue. So either the hypothesis is wrong or there is
something more subtle going on.

We don't know what is causing this issue yet and therefore neither
holding up the push gate nor force pushing seem appropriate under the

> It is not reasonable to revert a correct change because it has exposed
> an existing race condition elsewhere.  IMO, this should have been a
> force push to mark the test as non-blocking.
> ~Andrew

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.