device: 0.818 other: 0.788 semantic: 0.774 graphic: 0.751 assembly: 0.745 mistranslation: 0.719 KVM: 0.708 instruction: 0.661 network: 0.659 vnc: 0.640 socket: 0.624 boot: 0.609 [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: 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. ohh what's a qed device? quy: it might be a workaround to use a qcow2 image for now ahh the wiki has a statement "It is not recommended to use QED for any new images. " 'qed' was an experimental disk image format created by IBM before qcow2 v3 came along honestly nothing should ever use QED these days the good ideas from QED became qcow2v3 danpb: sounds like we should put a warning on the option to remind users of that fact quy: sounds like qed driver is simply broken - please do file a bug against qemu bug tracker quy: but you should also really switch to qcow2 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. quy: we can only be responsible for our own wiki I'm afraid... if you remember where you saw that please let us know so we can try to get it fixed 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. quy: an email to the mailing list would suffice too if you can't deal with launchpad 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: > 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. > ohh what's a qed device? > quy: it might be a workaround to use a qcow2 image for now > ahh the wiki has a statement "It is not recommended to use > QED for any new images. " > 'qed' was an experimental disk image format created by IBM > before qcow2 v3 came along > honestly nothing should ever use QED these days > the good ideas from QED became qcow2v3 > danpb: sounds like we should put a warning on the option to > remind users of that fact > quy: sounds like qed driver is simply broken - please do file > a bug against qemu bug tracker > quy: but you should also really switch to qcow2 > 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. > quy: we can only be responsible for our own wiki I'm afraid... > if you remember where you saw that please let us know so we > can try to get it fixed > 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. > quy: an email to the mailing list would suffice too if you > can't deal with launchpad > 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