qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] can we disable the migration-test for TCG targets ?


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] can we disable the migration-test for TCG targets ?
Date: Tue, 26 Feb 2019 13:55:41 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

* Peter Maydell (address@hidden) wrote:
> On Tue, 26 Feb 2019 at 12:30, Peter Maydell <address@hidden> wrote:
> >
> > On Tue, 26 Feb 2019 at 12:17, Dr. David Alan Gilbert
> > <address@hidden> wrote:
> > >
> > > * Peter Maydell (address@hidden) wrote:
> > > > Backtrace of process 125450:
> > > > Thread 6 (Thread 0xfff800012de0b900 (LWP 127434)):
> > > > #0  0xfff80001034c5cdc in futex_abstimed_wait_cancelable (private=0,
> > > > abstime=0xfff800012de09f88, expected=0, futex_word=0x10001236574)
> > > >     at ../sysdeps/unix/sysv/linux/futex-internal.h:205
> > > > #1  0xfff80001034c5cdc in do_futex_wait (sem=0x3c,
> > > > abstime=0xfff800012de09f88) at sem_waitcommon.c:111
> > > > #2  0xfff80001034c5e00 in __new_sem_wait_slow (sem=0x10001236570,
> > > > abstime=0xfff800012de09f88) at sem_waitcommon.c:181
> > > > #3  0x000001000091dacc in qemu_sem_timedwait (sem=0x10001236570,
> > > > ms=<optimized out>) at /home/pm215/qemu/util/qemu-thread-posix.c:289
> > > > #4  0x000001000078ae28 in migration_thread (opaque=0x100012364a0) at
> > > > /home/pm215/qemu/migration/migration.c:3125
> > >
> > > So migration is still apparently running, it's rate-limiting
> > > using a timedwait; but 'ms' has been unhelpfully optimised out; could
> > > it be stuck in here for some reason?
> >
> > I looked at this from frame 4, and ms is 64. On the other
> > hand if I tell gdb to 'fin' it doesn't ever leave
> > futex_abstimed_wait_cancelable(), so I wonder if we're
> > managing to get the conversion of the relative time into
> > an absolute deadline wrong somehow ??
> 
> Very weirdly, gdb shows me an absolute timestamp passed
> to the futex function which is indeed in the past, so it
> seems like the issue is that the kernel isn't returning
> control to us when the timestamp expires for some reason.

I wonder if we have any more luck with blacklisting CONFIG_SEM_TIMEDWAIT
- I wonder if it uses a different kernel call?

Dave

> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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