[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