From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YB1Nj-0005zt-KS for qemu-devel@nongnu.org; Tue, 13 Jan 2015 08:19:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YB1Ng-0002Vo-8M for qemu-devel@nongnu.org; Tue, 13 Jan 2015 08:19:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YB1Ng-0002VM-0Q for qemu-devel@nongnu.org; Tue, 13 Jan 2015 08:19:36 -0500 Date: Tue, 13 Jan 2015 13:19:31 +0000 From: Stefan Hajnoczi Message-ID: <20150113131931.GB21941@stefanha-thinkpad.redhat.com> References: <1421080834-14724-1-git-send-email-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PULL v2 00/44] Block patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2015 at 09:43:28PM +0000, Peter Maydell wrote: > On 12 January 2015 at 16:39, Stefan Hajnoczi wrote: > > The following changes since commit 64ea8038ffbf703dcd438a108d2d5499c8ff= 95d9: > > > > Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20150= 109.0' into staging (2015-01-10 22:29:09 +0000) > > > > are available in the git repository at: > > > > git://github.com/stefanha/qemu.git tags/block-pull-request > > > > for you to fetch changes up to bed6f0227ef9da1505758a63bd2b6cd2a45874c6: > > > > NVMe: Set correct VS Value for 1.1 Compliant Controllers (2015-01-12 = 16:30:28 +0000) >=20 > I'm afraid this fails 'make check' on at least one config and > generates a lot of ugly warnings on several. >=20 > (1) Ugly warning (seems to happen everywhere): >=20 > TEST: tests/virtio-blk-test... (pid=3D28666) > /arm/virtio/blk/mmio/basic: > WARNING: Image format was not specified for '/tmp/qtest.q0ywpl' and > probing guessed raw. > Automatically detecting the format is dangerous for raw > images, write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > OK I am dropping the series because of the timeout you discovered below. The fix for the warning is easy and I will let Marc know. > (2) Apparent errors on OSX when trying to use "/dev/null" as an > image file. Weirdly these don't actually cause "make check" to fail, > which suggests something's not propagating an error correctly. >=20 > GTESTER check-qtest-i386 > blkdebug: Suspended request 'A' > blkdebug: Resuming request 'A' > qemu-system-i386: -drive if=3Dnone,id=3Ddrive0,file=3D/dev/null,format=3D= raw: > could not open disk image /dev/null: Could not refresh total sector > count: Operation not supported by device I have dropped "block/raw-posix.c: Fixes raw_getlength() on Mac OS X so that it reports the correct length of a real CD". It breaks non-CD-ROM character devices like /dev/null. > (3) Actual failure, x86_64 host: >=20 > TEST: tests/virtio-blk-test... (pid=3D16564) > /arm/virtio/blk/mmio/basic: > WARNING: Image format was not specified for '/tmp/qtest.4s4Naf' and > probing guessed raw. > Automatically detecting the format is dangerous for raw > images, write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > ** > ERROR:/home/petmay01/linaro/qemu-for-merges/tests/libqos/virtio.c:91:qvir= tio_wait_queue_isr: > assertion failed: (g_get_monotonic_time() - start_time <=3D timeout_us) > FAIL > GTester: last random seed: R02S2b2c6e34351d711919b868b92fde3543 > (pid=3D16570) > FAIL: tests/virtio-blk-test >=20 > This might be an intermittent failure; I think my x86-64 gcc > build passed the first time and failed on a rerun. The clang > build also failed this. This is strange. The timeout is 30 seconds so something must be very wrong. I haven't been able to reproduce it yet but will ask Marc to investigate. Stefan --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtRtjAAoJEJykq7OBq3PIOBoIAJ+6sCBdyYW16IzRvka/hIf5 FTedRoa5plTToXtFjyxY1OZuctdN6UEl/JeBMVO8ODGEH8ruvBR9rLQXieRKDlW8 iXp0UKsYR0Z7ZjxxKQPkVqfpf9RAPby+XSABnyqEiT3h3BNUkBj2QzQluLlDWaTr BHh2cMpbYKU1tl79s3bG4StxHyeLjzXzVxBf2Ub14LXdhSoGX31hPd7gDUbQL1DI xon2IgxJyg+dBZr+YOq5Wq3e8IjHVJGQZEe0G8A38GSS6Dx4pGKUm085zgO215Oj whYFVn3SDpqTVNr74GpXXU8VXBb2Bot55ds8oP4kBgGub/+lc/kmLQGJLwooo64= =H3x0 -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2--