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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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

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