From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [xen-unstable test] 56759: regressions - FAIL Date: Tue, 26 May 2015 11:22:16 +0200 Message-ID: <55643B48.8010501@citrix.com> References: <1432115769.12989.219.camel@citrix.com> <556438C6.10507@citrix.com> <1432631857.14664.76.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1432631857.14664.76.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Tim Deegan , xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com, David Vrabel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Hi Ian, On 26/05/2015 11:17, Ian Campbell wrote: > On Tue, 2015-05-26 at 11:11 +0200, Julien Grall wrote: >> Hi, >> >> On 20/05/2015 11:56, Ian Campbell wrote: >>> On Wed, 2015-05-20 at 09:34 +0000, osstest service user wrote: >>>> flight 56759 xen-unstable real [real] >>>> http://logs.test-lab.xenproject.org/osstest/logs/56759/ >>>> >>>> Regressions :-( >>>> >>>> Tests which did not succeed and are blocking, >>>> including tests which could not be run: >>>> test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375 >>> >>> I'm pretty hard pressed to explain this from the set of commits >>> currently under test, but it has happened a few times now (e.g. 56700 >>> 56576) so it does seem to be real. >>> >>> http://logs.test-lab.xenproject.org/osstest/results/bisect.xen-unstable.test-armhf-armhf-xl-multivcpu.leak-check--check.html >>> is working on it and is currently consider the set of changes from: >>> ianc@cosworth:xen.git$ git log --oneline 9ab42~1...45fcc4 >>> 45fcc45 use ticket locks for spin locks >>> e13013d libxc/restore: add checkpointed flag to the restore context >>> ce44b40 libxc/restore: introduce setup() and cleanup() on restore >>> c5c5a04 libxc/restore: split read/handle qemu info >>> 9ab42c9 libxc/restore: introduce process_record() >>> >>> where e13013d is current master which was pushed in by flight 56375. >>> >>> I think it unlikely the libxl stuff is responible, given we don't >>> migrate on ARM, which would seem to point to the ticket locks... >> >> The test is still failing on the latest flight [1]. Any update on this >> issue? > > The bisection got nowhere. > > I've tried to repro on the cubietruck on my desk and have gotten > nowhere. > > But I've just now noticed that the failures are on arndale (not sure why > I thought ct). We use the same Xen binary (hypervisor/tools) and the both platform right? I'm wondering if it's because the processor revision is not the same and we forgot to implement an errata. > Can I steal the arndale off your desk please? Go ahead. > BTW, it doesn't seem to be a 100% failure rate, e.g. 57271 seems to have > passed, despite testing the exact same thing as 57242. I sometimes saw another test failing for ARM too. Regards, -- Julien Grall