qemu-devel
[Top][All Lists]
Advanced

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

Re: hang in migration-test (s390 host)


From: Peter Maydell
Subject: Re: hang in migration-test (s390 host)
Date: Fri, 25 Mar 2022 11:08:15 +0000

On Fri, 25 Mar 2022 at 08:04, Juan Quintela <quintela@redhat.com> wrote:
> Laurent Vivier <lvivier@redhat.com> wrote:
> > Perhaps Juan or Thomas can help too (added to cc)
> >
> > Is this a regression?
> > It looks like a bug in QEMU as it doesn't move from cancelling to cancelled.
>
> Hi
>
> TCG never stops given.  And s390 makes things even more interesting.
> First of all, it is a pity that glib debug symbols are not loaded.


> Migration main thread in multifd_send_sync_main(), waiting for the
> semaphore in
>
>     for (i = 0; i < migrate_multifd_channels(); i++) {
>         MultiFDSendParams *p = &multifd_send_state->params[i];
>
>         trace_multifd_send_sync_main_wait(p->id);
>         qemu_sem_wait(&p->sem_sync);
>     }
>
> Knowing the value of i would be great.  See the end of the email, I
> think it is going to be 0.

Unfortunately something went wrong in my attempt to attach gdb
to the process, and the process got killed, so I no longer have
it to answer this question :-(

> >> [Inferior 1 (process 2772862) detached]
> >> ===========================================================
> >> PROCESS: 2772869
> >> gitlab-+ 2772869 2771497  0 Mar23 ?        00:00:00 [qemu-system-i38] 
> >> <defunct>
> >> /proc/2772869/exe: No such file or directory.
> >> Could not attach to process.  If your uid matches the uid of the target
> >> process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
> >> again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
> >> warning: process 2772869 is a zombie - the process has already terminated
> >> ptrace: Operation not permitted.
> >> /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/2772869:
> >> No such file or directory.
>
> I have no clue what is this process and what this have to do with this
> run, what can it be?  We already have two qemu's and a test harness
> programm.  Can this be from a previous test case that we are still
> waiting for?

Your guess is as good as mine. I do note that when I've seen this
hang before it has always been with a zombie process in the
process tree.

-- PMM



reply via email to

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