qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/pl


From: Peter Maydell
Subject: Re: [PATCH] tests/qtest/migration-test: Disable migration/multifd/tcp/plain/cancel
Date: Fri, 3 Mar 2023 12:05:47 +0000

On Fri, 3 Mar 2023 at 11:29, Thomas Huth <thuth@redhat.com> wrote:
>
> On 03/03/2023 12.18, Peter Maydell wrote:
> > On Fri, 3 Mar 2023 at 09:10, Juan Quintela <quintela@redhat.com> wrote:
> >>
> >> Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>> On Thu, Mar 02, 2023 at 05:22:11PM +0000, Peter Maydell wrote:
> >>>> migration-test has been flaky for a long time, both in CI and
> >>>> otherwise:
> >>>>
> >>>> https://gitlab.com/qemu-project/qemu/-/jobs/3806090216
> >>>> (a FreeBSD job)
> >>>>    32/648 
> >>>> ERROR:../tests/qtest/migration-helpers.c:205:wait_for_migration_status: 
> >>>> assertion failed: (g_test_timer_elapsed() < 
> >>>> MIGRATION_STATUS_WAIT_TIMEOUT) ERROR
> >>>>
> >>>> on a local macos x86 box:
> >
> >
> >
> >> What is really weird with this failure is that:
> >> - it only happens on non-x86
> >
> > No, I have seen it on x86 macos, and x86 OpenBSD
> >
> >> - on code that is not arch dependent
> >> - on cancel, what we really do there is close fd's for the multifd
> >>    channel threads to get out of the recv, i.e. again, nothing that
> >>    should be arch dependent.
> >
> > I'm pretty sure that it tends to happen when the machine that's
> > running the test is heavily loaded. You probably have a race condition.
>
> I think I can second that. IIRC I've seen it a couple of times on my x86
> laptop when running "make check -j$(nproc) SPEED=slow" here.

And another on-x86 failure case, just now, on the FreeBSD x86 CI job:
https://gitlab.com/qemu-project/qemu/-/jobs/3870165180

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]