From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYzg3-0005Ok-EO for qemu-devel@nongnu.org; Fri, 29 Jun 2018 16:07:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYzg2-00038F-Aq for qemu-devel@nongnu.org; Fri, 29 Jun 2018 16:07:31 -0400 References: From: John Snow Message-ID: Date: Fri, 29 Jun 2018 16:07:22 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [BUG] qed_aio_write_alloc: Assertion `s->allocating_acb == NULL' failed. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Quytelda Kahja , qemu-devel@nongnu.org Cc: Qemu-block 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 >