On Tue, May 09, 2017 at 12:03:30PM -0400, Jeff Cody wrote:
> On Tue, May 09, 2017 at 11:15:06AM +0100, Richard W.M. Jones wrote:
> >
> > No I'm afraid this patch series does not fix the bug.
> >
> > The stack trace is below.
> >
> > Rich.
> >
>
> I'm looking through qemu-defel, and I'm not fin
On 09/05/2017 18:03, Jeff Cody wrote:
> On Tue, May 09, 2017 at 11:15:06AM +0100, Richard W.M. Jones wrote:
>>
>> No I'm afraid this patch series does not fix the bug.
>>
>> The stack trace is below.
>>
>> Rich.
>>
>
> I'm looking through qemu-defel, and I'm not finding a reference to the bug
>
On Tue, May 09, 2017 at 11:15:06AM +0100, Richard W.M. Jones wrote:
>
> No I'm afraid this patch series does not fix the bug.
>
> The stack trace is below.
>
> Rich.
>
I'm looking through qemu-defel, and I'm not finding a reference to the bug
mentioned. Maybe I'm just missing it... can you de
No I'm afraid this patch series does not fix the bug.
The stack trace is below.
Rich.
Thread 4 (Thread 0x7f8595cf1700 (LWP 11235)):
#0 0x7f86348e6700 in do_futex_wait () at /lib64/libpthread.so.0
#1 0x7f86348e6813 in __new_sem_wait_slow () at /lib64/libpthread.so.0
#2 0x5610e4585
This is the full version of the simple patch:
@@ -473,7 +475,9 @@
break;
}
if (!state) {
+qemu_mutex_unlock(&s->mutex);
aio_poll(bdrv_get_aio_context(bs), true);
+qemu_mutex_lock(&s->mutex);
}
} while(!state);
that
