path: root/results/classifier/007/other/57231878

permissions: 0.856
device: 0.818
other: 0.788
semantic: 0.774
graphic: 0.751
debug: 0.732
KVM: 0.708
PID: 0.684
network: 0.659
performance: 0.644
vnc: 0.640
socket: 0.624
boot: 0.609
files: 0.587

[Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed.

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.

For the sake of anyone else simply googling for a workaround, I'll
just paste in the (cleaned up) brief IRC conversation about my issue
from the official channel:
<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux,
Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine
(FreeBSD-11.1).  The VM always aborts at the same point in the
installation (downloading 'ports.tgz') with the following error
message:
"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197:
qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed.
zsh: abort (core dumped)  qemu-system-x86_64 -smp 2 -m 4096
-enable-kvm -hda freebsd/freebsd.qed -devic"
The commands I ran to create the machine are as follows:
"qemu-img create -f qed freebsd/freebsd.qed 16G"
"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda
freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0
-cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d"
I tried adding logging options with the -d flag, but I didn't get
anything that seemed relevant, since I'm not sure what to look for.
<stsquad> ohh what's a qed device?
<stsquad> quy: it might be a workaround to use a qcow2 image for now
<stsquad> ahh the wiki has a statement "It is not recommended to use
QED for any new images. "
<danpb> 'qed' was an experimental disk image format created by IBM
before qcow2 v3 came along
<danpb> honestly nothing should ever use  QED these days
<danpb> the good ideas from QED became  qcow2v3
<stsquad> danpb: sounds like we should put a warning on the option to
remind users of that fact
<danpb> quy: sounds like qed driver is simply broken - please do file
a bug against qemu bug tracker
<danpb> quy: but you should also really switch to qcow2
<quy> I see; some people need to update their wikis then.  I don't
remember where which guide I read when I first learned what little
QEMU I know, but I remember it specifically remember it saying QED was
the newest and most optimal format.
<stsquad> quy: we can only be responsible for our own wiki I'm afraid...
<danpb> if you remember where you saw that please let us know so we
can try to get it fixed
<quy> Thank you very much for the info; I will switch to QCOW.
Unfortunately, I'm not sure if I will be able to file any bug reports
in the tracker as I can't seem to log Launchpad, which it seems to
require.
<danpb> quy:  an email to the mailing list would suffice too if you
can't deal with launchpad
<danpb> kwolf: ^^^ in case you're interested in possible QED
assertions from 2.12

If any more info is needed, feel free to email me; I'm not actually
subscribed to this list though.
Thank you,
Quytelda Kahja

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.
>
>
For the sake of anyone else simply googling for a workaround, I'll
>
just paste in the (cleaned up) brief IRC conversation about my issue
>
from the official channel:
>
<quy> I'm using QEMU version 2.12.0 on an x86_64 host (Arch Linux,
>
Kernel v4.17.2), and I'm trying to create an x86_64 virtual machine
>
(FreeBSD-11.1).  The VM always aborts at the same point in the
>
installation (downloading 'ports.tgz') with the following error
>
message:
>
"qemu-system-x86_64: /build/qemu/src/qemu-2.12.0/block/qed.c:1197:
>
qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed.
>
zsh: abort (core dumped)  qemu-system-x86_64 -smp 2 -m 4096
>
-enable-kvm -hda freebsd/freebsd.qed -devic"
>
The commands I ran to create the machine are as follows:
>
"qemu-img create -f qed freebsd/freebsd.qed 16G"
>
"qemu-system-x86_64 -smp 2 -m 4096 -enable-kvm -hda
>
freebsd/freebsd.qed -device e1000,netdev=net0 -netdev user,id=net0
>
-cdrom FreeBSD-11.1-RELEASE-amd64-bootonly.iso -boot order=d"
>
I tried adding logging options with the -d flag, but I didn't get
>
anything that seemed relevant, since I'm not sure what to look for.
>
<stsquad> ohh what's a qed device?
>
<stsquad> quy: it might be a workaround to use a qcow2 image for now
>
<stsquad> ahh the wiki has a statement "It is not recommended to use
>
QED for any new images. "
>
<danpb> 'qed' was an experimental disk image format created by IBM
>
before qcow2 v3 came along
>
<danpb> honestly nothing should ever use  QED these days
>
<danpb> the good ideas from QED became  qcow2v3
>
<stsquad> danpb: sounds like we should put a warning on the option to
>
remind users of that fact
>
<danpb> quy: sounds like qed driver is simply broken - please do file
>
a bug against qemu bug tracker
>
<danpb> quy: but you should also really switch to qcow2
>
<quy> I see; some people need to update their wikis then.  I don't
>
remember where which guide I read when I first learned what little
>
QEMU I know, but I remember it specifically remember it saying QED was
>
the newest and most optimal format.
>
<stsquad> quy: we can only be responsible for our own wiki I'm afraid...
>
<danpb> if you remember where you saw that please let us know so we
>
can try to get it fixed
>
<quy> Thank you very much for the info; I will switch to QCOW.
>
Unfortunately, I'm not sure if I will be able to file any bug reports
>
in the tracker as I can't seem to log Launchpad, which it seems to
>
require.
>
<danpb> quy:  an email to the mailing list would suffice too if you
>
can't deal with launchpad
>
<danpb> kwolf: ^^^ in case you're interested in possible QED
>
assertions from 2.12
>
>
If any more info is needed, feel free to email me; I'm not actually
>
subscribed to this list though.
>
Thank you,
>
Quytelda Kahja
>

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
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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.

Kevin