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

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

>>> On 29.05.15 at 11:56, <andrew.cooper3@xxxxxxxxxx> 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.

If Ian gives his okay, I'm fine to re-instate the reverted patches (which
incidentally even got a push during the night), but I can't really see the
proof of what you claim in any of the earlier communication.

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

That's one way to view it. I'm not sure a force push would have been
warranted here, as the regression was real. And further holding up
the tree moving forward would have been bad in that situation too,
the more that it was - as said above - almost two weeks that it had
been stuck.


Xen-devel mailing list



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