From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uklt8-00046g-PE for qemu-devel@nongnu.org; Thu, 06 Jun 2013 21:54:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uklt6-0000ic-5w for qemu-devel@nongnu.org; Thu, 06 Jun 2013 21:54:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uklt5-0000iV-Ui for qemu-devel@nongnu.org; Thu, 06 Jun 2013 21:54:44 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r571sgtK003990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Jun 2013 21:54:42 -0400 Date: Fri, 7 Jun 2013 09:54:42 +0800 From: Fam Zheng Message-ID: <20130607015442.GA22188@localhost.nay.redhat.com> References: <1370499959-8916-1-git-send-email-famz@redhat.com> <20130606110157.GM4515@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130606110157.GM4515@redhat.com> Subject: Re: [Qemu-devel] [PATCH v7 00/13] curl: fix curl read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Thu, 06/06 12:01, Richard W.M. Jones wrote: > On Thu, Jun 06, 2013 at 02:25:46PM +0800, Fam Zheng wrote: > > v7: > > 13: Added: > > curl: change timeout to 30 seconds > > I tested this against: > > (1) HTTP to Apache server over slow but local wifi. > > (2) HTTP to a remote ISO (on another continent). > > Test (1) is fine. > > Test (2) gives plenty of I/O errors. I guess that 30 seconds isn't > sufficient here. > > I should note that current upstream qemu *works* in both cases. > Although the timeout in current qemu is much shorter (5 seconds), for > some reason this does not affect the test. > > I'm also confused about what problem this patch series is trying to > fix, since upstream qemu works fine for me with the latest curl. > The weird thing is it doesn't work for me, I'm sure something is wrong with current upstream, although not totally broken. $./qemu-io http://localhost/vm/arch.raw -c 'read -v 0 512' (stuck here forever, no output) Attach with gdb: (gdb) bt #0 aio_dispatch (ctx=0xaa1af230) at aio-posix.c:128 #1 0x00007f6fa96a18f7 in aio_poll (ctx=0x7f6faa1afa00, blocking=true) at aio-posix.c:190 #2 0x00007f6fa96ecabc in qemu_aio_wait () at main-loop.c:484 #3 0x00007f6fa96a7530 in bdrv_rwv_co (bs=0x7f6faa1b9540, sector_num=0, qiov=0x7fffacf403b0, is_write=false) at block.c:2216 #4 0x00007f6fa96a75ca in bdrv_rw_co (bs=0x7f6faa1b9540, sector_num=0, buf=0x7fffacf406f0 "", nb_sectors=4, is_write=false) at block.c:2235 #5 0x00007f6fa96a7629 in bdrv_read (bs=0x7f6faa1b9540, sector_num=0, buf=0x7fffacf406f0 "", nb_sectors=4) at block.c:2242 #6 0x00007f6fa96a78f5 in bdrv_pread (bs=0x7f6faa1b9540, offset=0, buf=0x7fffacf406f0, count1=2048) at block.c:2304 #7 0x00007f6fa96a36f4 in find_image_format ( bs=0x7f6faa1b9540, filename=0x7fffacf4441d "http://localhost/vm/arch.raw", pdrv=0x7fffacf40f28) at block.c:542 #8 0x00007f6fa96a4a8a in bdrv_open (bs=0x7f6faa1b5b00, filename=0x7fffacf4441d "http://localhost/vm/arch.raw", options=0x7f6faa1b7500, flags=24578, drv=0x0) at block.c:1055 #9 0x00007f6fa970e803 in openfile ( name=0x7fffacf4441d "http://localhost/vm/arch.raw", flags=16386, growable=0) at qemu-io.c:1812 #10 0x00007f6fa970ef5b in main (argc=4, argv=0x7fffacf43308) at qemu-io.c:2055 The BlockDriverState looks normal, just that libcurl not making any progress (no callback, no timeout) -- Fam