[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->a
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. |
Date: |
Mon, 2 Jul 2018 14:55:02 +0100 |
User-agent: |
Mutt/1.10.0 (2018-05-17) |
On Fri, Jun 29, 2018 at 10:35:28PM +0200, Kevin Wolf wrote:
> Am 29.06.2018 um 22:16 hat Eric Blake geschrieben:
> > On 06/29/2018 03:07 PM, John Snow wrote:
> > > CC Qemu Block; looks like QED is a bit busted.
> > >
> > > On 06/27/2018 10:25 AM, Quytelda Kahja wrote:
> > > > Hello all,
> > > > I wanted to submit a bug report in the tracker, but it seem to require
> > > > an Ubuntu One account, which I'm having trouble with, so I'll just
> > > > give it here and hopefully somebody can make use of it. The issue
> > > > seems to be in an experimental format, so it's likely not very
> > > > consequential anyway.
> >
> > Analysis in another thread may be relevant:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08963.html
>
> The assertion there was:
>
> qemu-system-x86_64: block.c:3434: bdrv_replace_node: Assertion
> `!atomic_read(&to->in_flight)' failed.
>
> Which quite clearly pointed to a drain bug. This one, however, doesn't
> seem to be related to drain, so I think it's probably a different bug.
Maybe there was a CoQueue regression in QEMU 2.10, 2.11, or 2.12.
My own commit c40a2545700e9ad2ef67d5972484bbee4c83b2a6 ("coroutine:
avoid co_queue_wakeup recursion") from QEMU 2.12.0 would be a good place
to start. I wonder if it fails before this commit.
git-bisect(1) could be used to track down the commit that broken qed,
although bisecting using a BSD installer sounds time-consuming.
Stefan
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-block] [Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed.,
Stefan Hajnoczi <=