Re: [PULL 0/2] block: Fix iotests to respect configured Python binary - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>, Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>
Subject: Re: [PULL 0/2] block: Fix iotests to respect configured Python binary
Date: Tue, 2 Feb 2021 15:43:09 +0300	[thread overview]
Message-ID: <0d4cb6de-b69e-1428-3686-3ac2e7dc80d1@virtuozzo.com> (raw)
In-Reply-To: <20210202114123.GB5184@merkur.fritz.box>

02.02.2021 14:41, Kevin Wolf wrote:
> Am 02.02.2021 um 10:47 hat Peter Maydell geschrieben:
>> On Fri, 29 Jan 2021 at 16:13, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> This is definitely better so I'm going to apply it, but it seems
>>> to reveal a pile of iotest failures on FreeBSD:
>>
>>> Failures: 030 040 041 127 256
>>
>> It seems to consistently be these five. What do they have in common ?
> 
> That's a very good question, especially if you ask what they have in
> common with each other, but with no other test.
> 
> With 030 040 041, your theory of running out of memory seemed to make a
> lot of sense because these are the big block job tests. But 127 doesn't
> fit in that group at all, it's a very small test on a tiny 64k image.
> Unlike the other tests in your list that make use of our Python
> framework, it's also just a shell script.
> 
> Other criteria that make 127 special like that it uses scsi and/or
> iothreads don't apply to all other failed cases, but instead to other
> cases that pass.
> 
> Are you still getting the same error message and is it the same for all
> Python test cases? ("Unexpected empty reply from server") If QEMU had
> been killed, there should be a message telling with which signal it
> exited (if that code works correctly on NetBSD).
> 
> In any case, the output for 127 must be different because it doesn't use
> the Python framework. Can you post the diff for that one?
> 


I reproduced once (didn't save any logs). Now I patched check-block:

--- a/tests/check-block.sh
+++ b/tests/check-block.sh
@@ -77,7 +77,7 @@ export PYTHONUTF8=1
  
  ret=0
  for fmt in $format_list ; do
-    ${PYTHON} ./check -makecheck -$fmt $group || ret=1
+    ${PYTHON} ./check -d -$fmt 30 || ret=1
  done

to see some information when it fails and try to reproduce again.

Hmm.

I've run

   make -j9 vm-build-netbsd J=9

two hours ago, and it's still running.

it's now at position

....
[6353/6384] Linking target storage-daemon/qemu-storage-daemon
ld: /usr/lib/libc.so and /usr/lib/crt0.o: warning: multiple common of `environ'
ld: warning: libintl.so.1, needed by /usr/pkg/lib/libgnutls.so, may conflict with libintl.so.8
[6354/6384] Linking target qemu-system-rx
ld: /usr/lib/libc.so and /usr/lib/crt0.o: warning: multiple common of `environ'
ld: warning: libintl.so.1, needed by /usr/pkg/lib/libgio-2.0.so, may conflict with libintl.so.8
[6355/6384] Linking target qemu-system-s390x
ld: /usr/lib/libc.so and /usr/lib/crt0.o: warning: multiple common of `environ'
ld: warning: libintl.so.1, needed by /usr/pkg/lib/libgio-2.0.so, may conflict with libintl.so.8


Why is it so slow? Any options to make it faster?

-- 
Best regards,
Vladimir

