On Tue, 26 Feb 2019 at 12:17, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > > * Peter Maydell (peter.mayd...@linaro.org) 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 ?? thanks -- PMM