From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPAr9-00073O-Ql for qemu-devel@nongnu.org; Fri, 10 Jul 2009 03:49:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPAr5-000739-4M for qemu-devel@nongnu.org; Fri, 10 Jul 2009 03:49:19 -0400 Received: from [199.232.76.173] (port=46631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPAr5-000736-2Z for qemu-devel@nongnu.org; Fri, 10 Jul 2009 03:49:15 -0400 Received: from mx20.gnu.org ([199.232.41.8]:3860) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPAr4-0003A8-Gl for qemu-devel@nongnu.org; Fri, 10 Jul 2009 03:49:14 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPAr3-00028u-Ek for qemu-devel@nongnu.org; Fri, 10 Jul 2009 03:49:13 -0400 Message-ID: <4A56F22A.8030406@redhat.com> Date: Fri, 10 Jul 2009 09:47:54 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu-iotests: make a few more tests generic References: <20090708194143.GA14640@lst.de> <4A55BF62.9070702@redhat.com> <20090709132513.GA13722@lst.de> In-Reply-To: <20090709132513.GA13722@lst.de> Content-Type: multipart/mixed; boundary="------------040400080904070708010402" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Anthony Liguori , qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------040400080904070708010402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christoph Hellwig schrieb: > On Thu, Jul 09, 2009 at 11:58:58AM +0200, Kevin Wolf wrote: >> Christoph Hellwig schrieb: >>> Pretend that a non-implemented check is always successful and thus allow >>> various tests that were qcow2-specific before to be generic. >> Looks good in general. However, vmdk and vpc fail test case 011 for me. >> Not sure yet where the problem actually is, there seems to be no qemu-io >> output at all for these. > > They pass for me. So I guess we have a problem somewhere that we'll > eventually need to investigate. This problem has already be found. Avi's patch from almost three weeks ago fixes it. It really starts to get annoying. How am I supposed to work with commits only every other week (which is bad enough) and then patches are forgotten and probably won't be merged before another two weeks? I guess I should manage some local tree with fixes myself and move away from basing my work on git master... Attaching Avi's patch for reference. Kevin --------------040400080904070708010402 Content-Type: text/plain; name="0001-block-Clean-up-after-deleting-BHs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-block-Clean-up-after-deleting-BHs.patch" >>From 3458d28d2a1eec3b867f7caa65ba177aa5b77da5 Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Tue, 23 Jun 2009 16:20:36 +0300 Subject: [PATCH] block: Clean up after deleting BHs Commit 6a7ad299 ("Call qemu_bh_delete at bdrv_aio_bh_cb") deletes emulated aio bottom halves to prevent endless accumulation. However, it leaves a stale ->bh pointer, which is then waited on when the aio is reused. Zeroing the pointer fixes the issue, allowing vmdk format images to be used. Signed-off-by: Avi Kivity --- block.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/block.c b/block.c index aca5a6d..cefbe77 100644 --- a/block.c +++ b/block.c @@ -1374,6 +1374,7 @@ static void bdrv_aio_cancel_em(BlockDriverAIOCB *blockacb) { BlockDriverAIOCBSync *acb = (BlockDriverAIOCBSync *)blockacb; qemu_bh_delete(acb->bh); + acb->bh = NULL; qemu_aio_release(acb); } @@ -1391,6 +1392,7 @@ static void bdrv_aio_bh_cb(void *opaque) qemu_vfree(acb->bounce); acb->common.cb(acb->common.opaque, acb->ret); qemu_bh_delete(acb->bh); + acb->bh = NULL; qemu_aio_release(acb); } -- 1.6.0.6 --------------040400080904070708010402--