On Tue, 26 Feb 2019 at 12:30, Peter Maydell <peter.mayd...@linaro.org> wrote: > > 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 ??
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. thanks -- PMM
