* Re: [Qemu-devel] make check speed
2017-08-23 8:35 ` Thomas Huth
@ 2017-08-23 8:52 ` Fam Zheng
2017-08-23 9:09 ` Fam Zheng
2017-08-23 9:33 ` Paolo Bonzini
` (2 subsequent siblings)
3 siblings, 1 reply; 38+ messages in thread
From: Fam Zheng @ 2017-08-23 8:52 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, Cornelia Huck, David Gibson, Peter Maydell,
Laurent Vivier, Michael S. Tsirkin, Richard Henderson,
QEMU Developers, Alex Bennée, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor
On Wed, 08/23 10:35, Thomas Huth wrote:
> Is it safe nowadays to run "make check -j4" for example? Last time I
> tried (maybe 1 or 2 years ago), there were still issues since some tests
> were using hard-coded temporary file names, so the parallel tests were
> disturbing each other, for example...
We really should fix them.
Last year I wanted to get some speed up in patchew's "make check" jobs so I
tried this:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07713.html
On my laptop it can save 50% time as shown in the commit message, unfortunately
the patch didn't get enough traction, and I've since then rarely used -j in
"make check" command lines (what?!).
Fam
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 8:52 ` Fam Zheng
@ 2017-08-23 9:09 ` Fam Zheng
0 siblings, 0 replies; 38+ messages in thread
From: Fam Zheng @ 2017-08-23 9:09 UTC (permalink / raw)
To: Thomas Huth
Cc: Laurent Vivier, Peter Maydell, Michael S. Tsirkin, Cornelia Huck,
Richard Henderson, QEMU Developers, Philippe Mathieu-Daudé,
Cleber Rosa, Paolo Bonzini, Lukáš Doktor,
Alex Bennée, David Gibson
On Wed, 08/23 16:52, Fam Zheng wrote:
> On Wed, 08/23 10:35, Thomas Huth wrote:
> > Is it safe nowadays to run "make check -j4" for example? Last time I
> > tried (maybe 1 or 2 years ago), there were still issues since some tests
> > were using hard-coded temporary file names, so the parallel tests were
> > disturbing each other, for example...
>
> We really should fix them.
>
> Last year I wanted to get some speed up in patchew's "make check" jobs so I
> tried this:
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg07713.html
>
> On my laptop it can save 50% time as shown in the commit message, unfortunately
> the patch didn't get enough traction, and I've since then rarely used -j in
> "make check" command lines (what?!).
Spoke too soon, I forgot my git-publish hook has been doing "make check -j8" on
all patches I post, and it seems to work well.
Fam
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 8:35 ` Thomas Huth
2017-08-23 8:52 ` Fam Zheng
@ 2017-08-23 9:33 ` Paolo Bonzini
2017-08-24 3:01 ` David Gibson
2017-08-23 11:51 ` Lukáš Doktor
2017-08-23 12:20 ` Cornelia Huck
3 siblings, 1 reply; 38+ messages in thread
From: Paolo Bonzini @ 2017-08-23 9:33 UTC (permalink / raw)
To: Thomas Huth, Cornelia Huck, David Gibson
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor
On 23/08/2017 10:35, Thomas Huth wrote:
>> If you have a many-core machine, of course, there's no simpler solution
>> than throwing more CPUs at it. :)
> Is it safe nowadays to run "make check -j4" for example? Last time I
> tried (maybe 1 or 2 years ago), there were still issues since some tests
> were using hard-coded temporary file names, so the parallel tests were
> disturbing each other, for example...
I run -j18 all the time. :)
Paolo
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 9:33 ` Paolo Bonzini
@ 2017-08-24 3:01 ` David Gibson
0 siblings, 0 replies; 38+ messages in thread
From: David Gibson @ 2017-08-24 3:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Thomas Huth, Cornelia Huck, Peter Maydell, Laurent Vivier,
Michael S. Tsirkin, Richard Henderson, QEMU Developers,
Alex Bennée, Fam Zheng, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
On Wed, Aug 23, 2017 at 11:33:55AM +0200, Paolo Bonzini wrote:
> On 23/08/2017 10:35, Thomas Huth wrote:
> >> If you have a many-core machine, of course, there's no simpler solution
> >> than throwing more CPUs at it. :)
> > Is it safe nowadays to run "make check -j4" for example? Last time I
> > tried (maybe 1 or 2 years ago), there were still issues since some tests
> > were using hard-coded temporary file names, so the parallel tests were
> > disturbing each other, for example...
>
> I run -j18 all the time. :)
Nice for those that have 18-way machines at their regular disposal...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 8:35 ` Thomas Huth
2017-08-23 8:52 ` Fam Zheng
2017-08-23 9:33 ` Paolo Bonzini
@ 2017-08-23 11:51 ` Lukáš Doktor
2017-08-23 12:01 ` Thomas Huth
2017-08-23 12:35 ` Thomas Huth
2017-08-23 12:20 ` Cornelia Huck
3 siblings, 2 replies; 38+ messages in thread
From: Lukáš Doktor @ 2017-08-23 11:51 UTC (permalink / raw)
To: Thomas Huth, Paolo Bonzini, Cornelia Huck, David Gibson
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa
[-- Attachment #1: Type: text/plain, Size: 4436 bytes --]
Dne 23.8.2017 v 10:35 Thomas Huth napsal(a):
> On 23.08.2017 10:01, Paolo Bonzini wrote:
>> On 23/08/2017 09:49, Thomas Huth wrote:
>>> While we're at it: I'd like to have a "make check-fast", too. Sometimes
>>> the normal "make check" is already too slow, e.g. while developing new
>>> patches, I sometimes just want to do a very quick sanity test to see
>>> whether I broke some basic things or not, and only do the "make check"
>>> before I submit my patches.
>>> So we would get three stages:
>>>
>>> - make check-fast => For very, very quick sanity tests only
>>>
>>> - make check => E.g. has to be run before submitting patches
>>>
>>> - make check-harder => might run a very long time, so best suited for
>>> nightly regression tests etc.?
>>>
>>> Does that sound reasonable? And the crucial question: Who is going to
>>> implement the basic framework for this?
>>
>> There's already make check-unit or make check-qtest-x86_64 depending on
>> what you're working on.
>
> True. And I just learned that you can also already set the SPEED
> variable to either "quick" or "slow" and that we're already using
> g_test_quick() and g_test_slow() in a couple of places to check this. So
> the framework for running quick vs. thorough tests is already there ...
> we just might want to add this to some more tests, I guess...
>
> Question for the maintainers and the test automation folks: Is anybody
> already running "make check SPEED=slow" or is this just rather an
> unheard-of way of running the tests?
>
>> If you have a many-core machine, of course, there's no simpler solution
>> than throwing more CPUs at it. :)
>
> Is it safe nowadays to run "make check -j4" for example? Last time I
> tried (maybe 1 or 2 years ago), there were still issues since some tests
> were using hard-coded temporary file names, so the parallel tests were
> disturbing each other, for example...
>
Actually the `.travis.yml` defines `MAKEFLAGS="-j3"`, which results in `make check` being executed with 3 threads...
I was actually looking at the increasing number of failed travis builds and it seems to be related to the fluctuating performance. Running `nice -n 20 make check -j 12` with `nice -n 5 stress -c 20` in background results in the same kind of failures:
File '/tmp/qemu/include/qapi/qmp/qobject.h'
Lines executed:0.00% of 9
**
ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de)
GTester: last random seed: R02S117a2b838f1fd17c65a134629577b996
make: *** [check-qtest-ppc] Chyba 1
/tmp/qemu/tests/Makefile.include:836: návod pro cíl „check-qtest-ppc“ selhal
make: *** [check-qtest-sparc] Chyba 1
/tmp/qemu/tests/Makefile.include:836: návod pro cíl „check-qtest-sparc“ selhal
**
ERROR:tests/rtc-test.c:173:check_time: assertion failed (ABS(t - s) <= wiggle): (3 <= 2)
GTester: last random seed: R02S2ca82eb2e7f63ec62c8433b715d9fe12
Vhost user backend fails to broadcast fake RARP
**
ERROR:tests/vhost-user-test.c:779:test_reconnect: child process (/i386/vhost-user/reconnect/subprocess [5264]) failed unexpectedly
GTester: last random seed: R02S6e728ccb5384a4d856cacc4166be8052
Gcov report for hw/misc/tmp105.c:
File 'hw/misc/tmp105.c'
Lines executed:30.40% of 125
Gcov report for arm-softmmu/hw/block/virtio-blk.c:
File '/tmp/qemu/hw/block/virtio-blk.c'
and all ERROR lines:
ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de)
ERROR:tests/rtc-test.c:173:check_time: assertion failed (ABS(t - s) <= wiggle): (3 <= 2)
ERROR:tests/vhost-user-test.c:779:test_reconnect: child process (/i386/vhost-user/reconnect/subprocess [5264]) failed unexpectedly
ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/x86_64/vhost-user/connect-fail/subprocess [7751]) failed unexpectedly
ERROR:tests/vhost-user-test.c:835:test_flags_mismatch: child process (/x86_64/vhost-user/flags-mismatch/subprocess [7892]) failed unexpectedly
ERROR:tests/boot-sector.c:127:boot_sector_test: assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead)
on my machine. Using `make -j 1` or at least `make -j 2` could improve (but I haven't checked that)
Lukáš
> Thomas
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 502 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 11:51 ` Lukáš Doktor
@ 2017-08-23 12:01 ` Thomas Huth
2017-08-23 12:13 ` Lukáš Doktor
2017-08-23 12:35 ` Thomas Huth
1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-23 12:01 UTC (permalink / raw)
To: Lukáš Doktor, Paolo Bonzini, Cornelia Huck, David Gibson
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]
On 23.08.2017 13:51, Lukáš Doktor wrote:
> Dne 23.8.2017 v 10:35 Thomas Huth napsal(a):
>> On 23.08.2017 10:01, Paolo Bonzini wrote:
>>> On 23/08/2017 09:49, Thomas Huth wrote:
>>>> While we're at it: I'd like to have a "make check-fast", too. Sometimes
>>>> the normal "make check" is already too slow, e.g. while developing new
>>>> patches, I sometimes just want to do a very quick sanity test to see
>>>> whether I broke some basic things or not, and only do the "make check"
>>>> before I submit my patches.
>>>> So we would get three stages:
>>>>
>>>> - make check-fast => For very, very quick sanity tests only
>>>>
>>>> - make check => E.g. has to be run before submitting patches
>>>>
>>>> - make check-harder => might run a very long time, so best suited for
>>>> nightly regression tests etc.?
>>>>
>>>> Does that sound reasonable? And the crucial question: Who is going to
>>>> implement the basic framework for this?
>>>
>>> There's already make check-unit or make check-qtest-x86_64 depending on
>>> what you're working on.
>>
>> True. And I just learned that you can also already set the SPEED
>> variable to either "quick" or "slow" and that we're already using
>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>> the framework for running quick vs. thorough tests is already there ...
>> we just might want to add this to some more tests, I guess...
>>
>> Question for the maintainers and the test automation folks: Is anybody
>> already running "make check SPEED=slow" or is this just rather an
>> unheard-of way of running the tests?
>>
>>> If you have a many-core machine, of course, there's no simpler solution
>>> than throwing more CPUs at it. :)
>>
>> Is it safe nowadays to run "make check -j4" for example? Last time I
>> tried (maybe 1 or 2 years ago), there were still issues since some tests
>> were using hard-coded temporary file names, so the parallel tests were
>> disturbing each other, for example...
>>
>
> Actually the `.travis.yml` defines `MAKEFLAGS="-j3"`, which results in `make check` being executed with 3 threads...
>
> I was actually looking at the increasing number of failed travis builds and it seems to be related to the fluctuating performance. Running `nice -n 20 make check -j 12` with `nice -n 5 stress -c 20` in background results in the same kind of failures:
>
> File '/tmp/qemu/include/qapi/qmp/qobject.h'
> Lines executed:0.00% of 9
> **
> ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de)
I think you're simply running into timeout issues here since you're
likely overloading the host, I guess. Or does your host have that many CPUs?
If the timeouts are really an issue here, we simply might have to
increase the timeout values a bit again...
Thomas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 12:01 ` Thomas Huth
@ 2017-08-23 12:13 ` Lukáš Doktor
2017-08-24 13:52 ` Cleber Rosa
0 siblings, 1 reply; 38+ messages in thread
From: Lukáš Doktor @ 2017-08-23 12:13 UTC (permalink / raw)
To: Thomas Huth, Paolo Bonzini, Cornelia Huck, David Gibson
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa
[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]
Dne 23.8.2017 v 14:01 Thomas Huth napsal(a):
> On 23.08.2017 13:51, Lukáš Doktor wrote:
>> Dne 23.8.2017 v 10:35 Thomas Huth napsal(a):
>>> On 23.08.2017 10:01, Paolo Bonzini wrote:
>>>> On 23/08/2017 09:49, Thomas Huth wrote:
>>>>> While we're at it: I'd like to have a "make check-fast", too. Sometimes
>>>>> the normal "make check" is already too slow, e.g. while developing new
>>>>> patches, I sometimes just want to do a very quick sanity test to see
>>>>> whether I broke some basic things or not, and only do the "make check"
>>>>> before I submit my patches.
>>>>> So we would get three stages:
>>>>>
>>>>> - make check-fast => For very, very quick sanity tests only
>>>>>
>>>>> - make check => E.g. has to be run before submitting patches
>>>>>
>>>>> - make check-harder => might run a very long time, so best suited for
>>>>> nightly regression tests etc.?
>>>>>
>>>>> Does that sound reasonable? And the crucial question: Who is going to
>>>>> implement the basic framework for this?
>>>>
>>>> There's already make check-unit or make check-qtest-x86_64 depending on
>>>> what you're working on.
>>>
>>> True. And I just learned that you can also already set the SPEED
>>> variable to either "quick" or "slow" and that we're already using
>>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>>> the framework for running quick vs. thorough tests is already there ...
>>> we just might want to add this to some more tests, I guess...
>>>
>>> Question for the maintainers and the test automation folks: Is anybody
>>> already running "make check SPEED=slow" or is this just rather an
>>> unheard-of way of running the tests?
>>>
>>>> If you have a many-core machine, of course, there's no simpler solution
>>>> than throwing more CPUs at it. :)
>>>
>>> Is it safe nowadays to run "make check -j4" for example? Last time I
>>> tried (maybe 1 or 2 years ago), there were still issues since some tests
>>> were using hard-coded temporary file names, so the parallel tests were
>>> disturbing each other, for example...
>>>
>>
>> Actually the `.travis.yml` defines `MAKEFLAGS="-j3"`, which results in `make check` being executed with 3 threads...
>>
>> I was actually looking at the increasing number of failed travis builds and it seems to be related to the fluctuating performance. Running `nice -n 20 make check -j 12` with `nice -n 5 stress -c 20` in background results in the same kind of failures:
>>
>> File '/tmp/qemu/include/qapi/qmp/qobject.h'
>> Lines executed:0.00% of 9
>> **
>> ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de)
>
> I think you're simply running into timeout issues here since you're
> likely overloading the host, I guess. Or does your host have that many CPUs?
> If the timeouts are really an issue here, we simply might have to
> increase the timeout values a bit again...
>
The reason I did this is that the `make check -j 12` runs for ~ 4 minutes on my machine (8 cores) while in travis it sometimes runs even more than 40 minutes. I wanted to get closer to see why is it failing and this might be the reason and yes, it's most certainly timeout issue. The problem with Travis is it gives quite decent power, but sometimes it's slowed for couple of seconds, or even minutes. This affects many of our (Avocado) selftests so we usually have timeouts between 10-60s for operations that usually take less than a second.
Lukáš
PS: Usually the `make check -j 12` works well on my machine...
> Thomas
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 502 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 12:13 ` Lukáš Doktor
@ 2017-08-24 13:52 ` Cleber Rosa
0 siblings, 0 replies; 38+ messages in thread
From: Cleber Rosa @ 2017-08-24 13:52 UTC (permalink / raw)
To: Lukáš Doktor, Thomas Huth, Paolo Bonzini,
Cornelia Huck, David Gibson
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé
[-- Attachment #1: Type: text/plain, Size: 4641 bytes --]
On 08/23/2017 08:13 AM, Lukáš Doktor wrote:
> Dne 23.8.2017 v 14:01 Thomas Huth napsal(a):
>> On 23.08.2017 13:51, Lukáš Doktor wrote:
>>> Dne 23.8.2017 v 10:35 Thomas Huth napsal(a):
>>>> On 23.08.2017 10:01, Paolo Bonzini wrote:
>>>>> On 23/08/2017 09:49, Thomas Huth wrote:
>>>>>> While we're at it: I'd like to have a "make check-fast", too. Sometimes
>>>>>> the normal "make check" is already too slow, e.g. while developing new
>>>>>> patches, I sometimes just want to do a very quick sanity test to see
>>>>>> whether I broke some basic things or not, and only do the "make check"
>>>>>> before I submit my patches.
>>>>>> So we would get three stages:
>>>>>>
>>>>>> - make check-fast => For very, very quick sanity tests only
>>>>>>
>>>>>> - make check => E.g. has to be run before submitting patches
>>>>>>
>>>>>> - make check-harder => might run a very long time, so best suited for
>>>>>> nightly regression tests etc.?
>>>>>>
>>>>>> Does that sound reasonable? And the crucial question: Who is going to
>>>>>> implement the basic framework for this?
>>>>>
>>>>> There's already make check-unit or make check-qtest-x86_64 depending on
>>>>> what you're working on.
>>>>
>>>> True. And I just learned that you can also already set the SPEED
>>>> variable to either "quick" or "slow" and that we're already using
>>>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>>>> the framework for running quick vs. thorough tests is already there ...
>>>> we just might want to add this to some more tests, I guess...
>>>>
>>>> Question for the maintainers and the test automation folks: Is anybody
>>>> already running "make check SPEED=slow" or is this just rather an
>>>> unheard-of way of running the tests?
>>>>
>>>>> If you have a many-core machine, of course, there's no simpler solution
>>>>> than throwing more CPUs at it. :)
>>>>
>>>> Is it safe nowadays to run "make check -j4" for example? Last time I
>>>> tried (maybe 1 or 2 years ago), there were still issues since some tests
>>>> were using hard-coded temporary file names, so the parallel tests were
>>>> disturbing each other, for example...
>>>>
>>>
>>> Actually the `.travis.yml` defines `MAKEFLAGS="-j3"`, which results in `make check` being executed with 3 threads...
>>>
>>> I was actually looking at the increasing number of failed travis builds and it seems to be related to the fluctuating performance. Running `nice -n 20 make check -j 12` with `nice -n 5 stress -c 20` in background results in the same kind of failures:
>>>
>>> File '/tmp/qemu/include/qapi/qmp/qobject.h'
>>> Lines executed:0.00% of 9
>>> **
>>> ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de)
>>
>> I think you're simply running into timeout issues here since you're
>> likely overloading the host, I guess. Or does your host have that many CPUs?
>> If the timeouts are really an issue here, we simply might have to
>> increase the timeout values a bit again...
>>
>
> The reason I did this is that the `make check -j 12` runs for ~ 4 minutes on my machine (8 cores) while in travis it sometimes runs even more than 40 minutes. I wanted to get closer to see why is it failing and this might be the reason and yes, it's most certainly timeout issue. The problem with Travis is it gives quite decent power, but sometimes it's slowed for couple of seconds, or even minutes. This affects many of our (Avocado) selftests so we usually have timeouts between 10-60s for operations that usually take less than a second.
And we learned that even huge timeouts are not a valid solution, in fact
they can become a counter solution. On many environments it's not wise
to even run tests are time sensitive. Travis is one, Fedora package
build hosts are another example.
IMO, this signals that test metadata (and categorization on top of it)
can be of great help in many situations. Instead of writing a multitude
of "make check-(you-characteristics-here)" targets, something like "make
EXCLUDE=time_senstitive check" is far more flexible.
Using Avocado as an example, it'd mean running something like:
$ avocado run -t '-time_sensitive,-superuser' tests/*
- Cleber.
>
> Lukáš
>
> PS: Usually the `make check -j 12` works well on my machine...
>
>> Thomas
>>
>
>
--
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 11:51 ` Lukáš Doktor
2017-08-23 12:01 ` Thomas Huth
@ 2017-08-23 12:35 ` Thomas Huth
2017-08-23 12:52 ` Lukáš Doktor
1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-23 12:35 UTC (permalink / raw)
To: Lukáš Doktor, Paolo Bonzini, Cornelia Huck,
David Gibson, Marc-André Lureau
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
On 23.08.2017 13:51, Lukáš Doktor wrote:
[...]
> and all ERROR lines:
>
> ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de)
This test uses a timeout of 120 s, see check_guest_memory() in
tests/prom-env-test.c ... that's a lot already, but if you hit this on a
real system, feel free to send a patch to increase the timeout.
> ERROR:tests/rtc-test.c:173:check_time: assertion failed (ABS(t - s) <= wiggle): (3 <= 2)
You might need to increase the "wiggle" variable here.
> ERROR:tests/vhost-user-test.c:779:test_reconnect: child process (/i386/vhost-user/reconnect/subprocess [5264]) failed unexpectedly
> ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/x86_64/vhost-user/connect-fail/subprocess [7751]) failed unexpectedly
> ERROR:tests/vhost-user-test.c:835:test_flags_mismatch: child process (/x86_64/vhost-user/flags-mismatch/subprocess [7892]) failed unexpectedly
I've got no clue about what could be wrong here ... maybe Marc-André can
advise here (who wrote these tests if I got "git blame" right).
> ERROR:tests/boot-sector.c:127:boot_sector_test: assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead)
Uses a timeout of 90 s ... feel free to send a patch to increase it if
it's necessary (the timeout can be found in boot_sector_test() in
tests/boot-sector.c).
Thomas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 12:35 ` Thomas Huth
@ 2017-08-23 12:52 ` Lukáš Doktor
0 siblings, 0 replies; 38+ messages in thread
From: Lukáš Doktor @ 2017-08-23 12:52 UTC (permalink / raw)
To: Thomas Huth, Paolo Bonzini, Cornelia Huck, David Gibson,
Marc-André Lureau
Cc: Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa
[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]
Dne 23.8.2017 v 14:35 Thomas Huth napsal(a):
> On 23.08.2017 13:51, Lukáš Doktor wrote:
> [...]
>> and all ERROR lines:
>>
>> ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de)
>
> This test uses a timeout of 120 s, see check_guest_memory() in
> tests/prom-env-test.c ... that's a lot already, but if you hit this on a
> real system, feel free to send a patch to increase the timeout.
>
>> ERROR:tests/rtc-test.c:173:check_time: assertion failed (ABS(t - s) <= wiggle): (3 <= 2)
>
> You might need to increase the "wiggle" variable here.
>
>> ERROR:tests/vhost-user-test.c:779:test_reconnect: child process (/i386/vhost-user/reconnect/subprocess [5264]) failed unexpectedly
>> ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/x86_64/vhost-user/connect-fail/subprocess [7751]) failed unexpectedly
>> ERROR:tests/vhost-user-test.c:835:test_flags_mismatch: child process (/x86_64/vhost-user/flags-mismatch/subprocess [7892]) failed unexpectedly
>
> I've got no clue about what could be wrong here ... maybe Marc-André can
> advise here (who wrote these tests if I got "git blame" right).
>
>> ERROR:tests/boot-sector.c:127:boot_sector_test: assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead)
>
> Uses a timeout of 90 s ... feel free to send a patch to increase it if
> it's necessary (the timeout can be found in boot_sector_test() in
> tests/boot-sector.c).
>
> Thomas
>
Well this one was produced by the `stress` command, so it does not reflect the reality. So this time I took the time and looked at the actual failures in David's travis results (his builds were already migrated to trusty and are failing massively) https://travis-ci.org/dgibson/qemu/builds I see only the `vhost-user-test` failing:
ERROR:tests/vhost-user-test.c:779:test_reconnect: child process (/x86_64/vhost-user/reconnect/subprocess [58907]) failed unexpectedly
ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/x86_64/vhost-user/connect-fail/subprocess [58924]) failed unexpectedly
ERROR:tests/vhost-user-test.c:835:test_flags_mismatch: child process (/i386/vhost-user/flags-mismatch/subprocess [56261]) failed unexpectedly
I actually looked there but I have no clue of how to fix this issue. But most probably it'd make Travis happier...
Lukáš
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 502 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 8:35 ` Thomas Huth
` (2 preceding siblings ...)
2017-08-23 11:51 ` Lukáš Doktor
@ 2017-08-23 12:20 ` Cornelia Huck
2017-08-24 5:27 ` Thomas Huth
2017-08-29 16:34 ` Thomas Huth
3 siblings, 2 replies; 38+ messages in thread
From: Cornelia Huck @ 2017-08-23 12:20 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, David Gibson, Peter Maydell, Laurent Vivier,
Michael S. Tsirkin, Richard Henderson, QEMU Developers,
Alex Bennée, Fam Zheng, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor
On Wed, 23 Aug 2017 10:35:43 +0200
Thomas Huth <thuth@redhat.com> wrote:
> True. And I just learned that you can also already set the SPEED
> variable to either "quick" or "slow" and that we're already using
> g_test_quick() and g_test_slow() in a couple of places to check this. So
> the framework for running quick vs. thorough tests is already there ...
> we just might want to add this to some more tests, I guess...
>
> Question for the maintainers and the test automation folks: Is anybody
> already running "make check SPEED=slow" or is this just rather an
> unheard-of way of running the tests?
So I tried this on master just for fun, and 'make V=1 SPEED=slow
check-qtest-x86_64' promptly failed for some ivshmem test.
On x86_86:
TEST: tests/ivshmem-test... (pid=3672)
/x86_64/ivshmem/single: OK
/x86_64/ivshmem/hotplug: OK
/x86_64/ivshmem/memdev: OK
/x86_64/ivshmem/pair: OK
/x86_64/ivshmem/server-msi: **
ERROR:/home/cohuck/git/qemu/tests/ivshmem-test.c:367:test_ivshmem_server: assertion failed (ret == 0): (1 == 0)
FAIL
GTester: last random seed: R02Scde8fd6835fdf17450c73e2f74f25007
(pid=3697)
/x86_64/ivshmem/server-irq: OK
FAIL: tests/ivshmem-test
On s390x:
TEST: tests/ivshmem-test... (pid=63617)
/x86_64/ivshmem/single: OK
/x86_64/ivshmem/hotplug: OK
/x86_64/ivshmem/memdev: OK
/x86_64/ivshmem/pair: OK
/x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
Broken pipe
FAIL
GTester: last random seed: R02Sda000f7be5ce27b3dfbb03d12f297b69
(pid=63640)
/x86_64/ivshmem/server-irq: qemu-system-x86_64: -device ivshmem,size=1M,msi=off,chardev=chr0,vectors=2: server sent invalid ID message
Broken pipe
FAIL
GTester: last random seed: R02S5a236dbcac35545cc34c0131fbc06162
(pid=63648)
FAIL: tests/ivshmem-test
Both machines are on Fedora 26.
(On the bright side, the rest of the test seemed fine.)
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 12:20 ` Cornelia Huck
@ 2017-08-24 5:27 ` Thomas Huth
2017-08-30 8:59 ` Cornelia Huck
2017-08-29 16:34 ` Thomas Huth
1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-24 5:27 UTC (permalink / raw)
To: Cornelia Huck
Cc: Paolo Bonzini, David Gibson, Peter Maydell, Laurent Vivier,
Michael S. Tsirkin, Richard Henderson, QEMU Developers,
Alex Bennée, Fam Zheng, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor, Marc-André Lureau,
Markus Armbruster, Cam Macdonell
On 23.08.2017 14:20, Cornelia Huck wrote:
> On Wed, 23 Aug 2017 10:35:43 +0200
> Thomas Huth <thuth@redhat.com> wrote:
>
>> True. And I just learned that you can also already set the SPEED
>> variable to either "quick" or "slow" and that we're already using
>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>> the framework for running quick vs. thorough tests is already there ...
>> we just might want to add this to some more tests, I guess...
>>
>> Question for the maintainers and the test automation folks: Is anybody
>> already running "make check SPEED=slow" or is this just rather an
>> unheard-of way of running the tests?
>
> So I tried this on master just for fun, and 'make V=1 SPEED=slow
> check-qtest-x86_64' promptly failed for some ivshmem test.
>
> On x86_86:
> TEST: tests/ivshmem-test... (pid=3672)
> /x86_64/ivshmem/single: OK
> /x86_64/ivshmem/hotplug: OK
> /x86_64/ivshmem/memdev: OK
> /x86_64/ivshmem/pair: OK
> /x86_64/ivshmem/server-msi: **
> ERROR:/home/cohuck/git/qemu/tests/ivshmem-test.c:367:test_ivshmem_server: assertion failed (ret == 0): (1 == 0)
> FAIL
> GTester: last random seed: R02Scde8fd6835fdf17450c73e2f74f25007
> (pid=3697)
> /x86_64/ivshmem/server-irq: OK
> FAIL: tests/ivshmem-test
>
> On s390x:
> TEST: tests/ivshmem-test... (pid=63617)
> /x86_64/ivshmem/single: OK
> /x86_64/ivshmem/hotplug: OK
> /x86_64/ivshmem/memdev: OK
> /x86_64/ivshmem/pair: OK
> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
> Broken pipe
> FAIL
> GTester: last random seed: R02Sda000f7be5ce27b3dfbb03d12f297b69
> (pid=63640)
> /x86_64/ivshmem/server-irq: qemu-system-x86_64: -device ivshmem,size=1M,msi=off,chardev=chr0,vectors=2: server sent invalid ID message
> Broken pipe
> FAIL
> GTester: last random seed: R02S5a236dbcac35545cc34c0131fbc06162
> (pid=63648)
> FAIL: tests/ivshmem-test
>
> Both machines are on Fedora 26.
The ivshmem test fails for me with SPEED=slow, too (on a x86 RHEL7
machine). Looks like it is definitely broken. Could anybody with some
ivshmem knowledge please have a look at this?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-24 5:27 ` Thomas Huth
@ 2017-08-30 8:59 ` Cornelia Huck
2017-08-30 9:13 ` Thomas Huth
0 siblings, 1 reply; 38+ messages in thread
From: Cornelia Huck @ 2017-08-30 8:59 UTC (permalink / raw)
To: Thomas Huth
Cc: Paolo Bonzini, David Gibson, Peter Maydell, Laurent Vivier,
Michael S. Tsirkin, Richard Henderson, QEMU Developers,
Alex Bennée, Fam Zheng, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor, Marc-André Lureau,
Markus Armbruster, Cam Macdonell
On Thu, 24 Aug 2017 07:27:18 +0200
Thomas Huth <thuth@redhat.com> wrote:
> On 23.08.2017 14:20, Cornelia Huck wrote:
> > So I tried this on master just for fun, and 'make V=1 SPEED=slow
> > check-qtest-x86_64' promptly failed for some ivshmem test.
> >
> > On x86_86:
> > TEST: tests/ivshmem-test... (pid=3672)
> > /x86_64/ivshmem/single: OK
> > /x86_64/ivshmem/hotplug: OK
> > /x86_64/ivshmem/memdev: OK
> > /x86_64/ivshmem/pair: OK
> > /x86_64/ivshmem/server-msi: **
> > ERROR:/home/cohuck/git/qemu/tests/ivshmem-test.c:367:test_ivshmem_server: assertion failed (ret == 0): (1 == 0)
> > FAIL
> > GTester: last random seed: R02Scde8fd6835fdf17450c73e2f74f25007
> > (pid=3697)
> > /x86_64/ivshmem/server-irq: OK
> > FAIL: tests/ivshmem-test
I think this one is understood now...
> >
> > On s390x:
> > TEST: tests/ivshmem-test... (pid=63617)
> > /x86_64/ivshmem/single: OK
> > /x86_64/ivshmem/hotplug: OK
> > /x86_64/ivshmem/memdev: OK
> > /x86_64/ivshmem/pair: OK
> > /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
> > Broken pipe
> > FAIL
> > GTester: last random seed: R02Sda000f7be5ce27b3dfbb03d12f297b69
> > (pid=63640)
> > /x86_64/ivshmem/server-irq: qemu-system-x86_64: -device ivshmem,size=1M,msi=off,chardev=chr0,vectors=2: server sent invalid ID message
> > Broken pipe
> > FAIL
> > GTester: last random seed: R02S5a236dbcac35545cc34c0131fbc06162
> > (pid=63648)
> > FAIL: tests/ivshmem-test
...but this is a different problem (i.e., it can't be tracked down to
commit b4ba67d9a7). I'm not sure whether that one ever worked. Might be
an endianness problem (a quick test on another BE platform could
confirm.)
> >
> > Both machines are on Fedora 26.
>
> The ivshmem test fails for me with SPEED=slow, too (on a x86 RHEL7
> machine). Looks like it is definitely broken. Could anybody with some
> ivshmem knowledge please have a look at this?
>
> Thanks,
> Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-30 8:59 ` Cornelia Huck
@ 2017-08-30 9:13 ` Thomas Huth
2017-08-30 11:52 ` Markus Armbruster
0 siblings, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-30 9:13 UTC (permalink / raw)
To: Cornelia Huck
Cc: Paolo Bonzini, David Gibson, Peter Maydell, Laurent Vivier,
Michael S. Tsirkin, Richard Henderson, QEMU Developers,
Alex Bennée, Fam Zheng, Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor, Marc-André Lureau,
Markus Armbruster, Cam Macdonell
On 30.08.2017 10:59, Cornelia Huck wrote:
[...]
>>> On s390x:
>>> TEST: tests/ivshmem-test... (pid=63617)
>>> /x86_64/ivshmem/single: OK
>>> /x86_64/ivshmem/hotplug: OK
>>> /x86_64/ivshmem/memdev: OK
>>> /x86_64/ivshmem/pair: OK
>>> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
>>> Broken pipe
>>> FAIL
>>> GTester: last random seed: R02Sda000f7be5ce27b3dfbb03d12f297b69
>>> (pid=63640)
>>> /x86_64/ivshmem/server-irq: qemu-system-x86_64: -device ivshmem,size=1M,msi=off,chardev=chr0,vectors=2: server sent invalid ID message
>>> Broken pipe
>>> FAIL
>>> GTester: last random seed: R02S5a236dbcac35545cc34c0131fbc06162
>>> (pid=63648)
>>> FAIL: tests/ivshmem-test
>
> ...but this is a different problem (i.e., it can't be tracked down to
> commit b4ba67d9a7). I'm not sure whether that one ever worked. Might be
> an endianness problem (a quick test on another BE platform could
> confirm.)
This also fails on a big endian ppc64 host machine:
$ uname -m
ppc64
$ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow
/x86_64/ivshmem/single: OK
/x86_64/ivshmem/hotplug: OK
/x86_64/ivshmem/memdev: OK
/x86_64/ivshmem/pair: OK
/x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
Broken pipe
Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-30 9:13 ` Thomas Huth
@ 2017-08-30 11:52 ` Markus Armbruster
2017-08-30 13:56 ` Thomas Huth
0 siblings, 1 reply; 38+ messages in thread
From: Markus Armbruster @ 2017-08-30 11:52 UTC (permalink / raw)
To: Thomas Huth
Cc: Cornelia Huck, Laurent Vivier, Peter Maydell, Cam Macdonell,
Fam Zheng, Michael S. Tsirkin, Richard Henderson,
QEMU Developers, Philippe Mathieu-Daudé,
Marc-André Lureau, Cleber Rosa, Paolo Bonzini,
Lukáš Doktor, Alex Bennée, David Gibson
Thomas Huth <thuth@redhat.com> writes:
> On 30.08.2017 10:59, Cornelia Huck wrote:
> [...]
>>>> On s390x:
>>>> TEST: tests/ivshmem-test... (pid=63617)
>>>> /x86_64/ivshmem/single: OK
>>>> /x86_64/ivshmem/hotplug: OK
>>>> /x86_64/ivshmem/memdev: OK
>>>> /x86_64/ivshmem/pair: OK
>>>> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
>>>> Broken pipe
>>>> FAIL
>>>> GTester: last random seed: R02Sda000f7be5ce27b3dfbb03d12f297b69
>>>> (pid=63640)
>>>> /x86_64/ivshmem/server-irq: qemu-system-x86_64: -device ivshmem,size=1M,msi=off,chardev=chr0,vectors=2: server sent invalid ID message
>>>> Broken pipe
>>>> FAIL
>>>> GTester: last random seed: R02S5a236dbcac35545cc34c0131fbc06162
>>>> (pid=63648)
>>>> FAIL: tests/ivshmem-test
>>
>> ...but this is a different problem (i.e., it can't be tracked down to
>> commit b4ba67d9a7). I'm not sure whether that one ever worked. Might be
>> an endianness problem (a quick test on another BE platform could
>> confirm.)
>
> This also fails on a big endian ppc64 host machine:
>
> $ uname -m
> ppc64
> $ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow
> /x86_64/ivshmem/single: OK
> /x86_64/ivshmem/hotplug: OK
> /x86_64/ivshmem/memdev: OK
> /x86_64/ivshmem/pair: OK
> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
> Broken pipe
Botched endian conversion?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-30 11:52 ` Markus Armbruster
@ 2017-08-30 13:56 ` Thomas Huth
2017-08-30 14:19 ` Markus Armbruster
0 siblings, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-30 13:56 UTC (permalink / raw)
To: Markus Armbruster
Cc: Cornelia Huck, Laurent Vivier, Peter Maydell, Cam Macdonell,
Fam Zheng, Michael S. Tsirkin, Richard Henderson,
QEMU Developers, Philippe Mathieu-Daudé,
Marc-André Lureau, Cleber Rosa, Paolo Bonzini,
Lukáš Doktor, Alex Bennée, David Gibson
On 30.08.2017 13:52, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
[...]
>> This also fails on a big endian ppc64 host machine:
>>
>> $ uname -m
>> ppc64
>> $ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow
>> /x86_64/ivshmem/single: OK
>> /x86_64/ivshmem/hotplug: OK
>> /x86_64/ivshmem/memdev: OK
>> /x86_64/ivshmem/pair: OK
>> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
>> Broken pipe
>
> Botched endian conversion?
Yes, it's an endianess problem. I just sent a patch, title
"hw/misc/ivshmem: Fix ivshmem_recv_msg() to also work on big endian
systems" (forgot to put you on CC:, sorry!).
Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-30 13:56 ` Thomas Huth
@ 2017-08-30 14:19 ` Markus Armbruster
0 siblings, 0 replies; 38+ messages in thread
From: Markus Armbruster @ 2017-08-30 14:19 UTC (permalink / raw)
To: Thomas Huth
Cc: Laurent Vivier, Peter Maydell, Fam Zheng, Michael S. Tsirkin,
Cornelia Huck, Richard Henderson, QEMU Developers,
Philippe Mathieu-Daudé,
Marc-André Lureau, Cleber Rosa, Lukáš Doktor,
Paolo Bonzini, Cam Macdonell, Alex Bennée, David Gibson
Thomas Huth <thuth@redhat.com> writes:
> On 30.08.2017 13:52, Markus Armbruster wrote:
>> Thomas Huth <thuth@redhat.com> writes:
> [...]
>>> This also fails on a big endian ppc64 host machine:
>>>
>>> $ uname -m
>>> ppc64
>>> $ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow
>>> /x86_64/ivshmem/single: OK
>>> /x86_64/ivshmem/hotplug: OK
>>> /x86_64/ivshmem/memdev: OK
>>> /x86_64/ivshmem/pair: OK
>>> /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
>>> Broken pipe
>>
>> Botched endian conversion?
>
> Yes, it's an endianess problem. I just sent a patch, title
> "hw/misc/ivshmem: Fix ivshmem_recv_msg() to also work on big endian
> systems" (forgot to put you on CC:, sorry!).
No need to be sorry! Because I always feel sorry when I have to review
another ivshmem patch ;-}
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-23 12:20 ` Cornelia Huck
2017-08-24 5:27 ` Thomas Huth
@ 2017-08-29 16:34 ` Thomas Huth
2017-08-29 17:13 ` Thomas Huth
1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2017-08-29 16:34 UTC (permalink / raw)
To: Cornelia Huck, David Gibson
Cc: Paolo Bonzini, Peter Maydell, Laurent Vivier, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Alex Bennée, Fam Zheng,
Philippe Mathieu-Daudé,
Cleber Rosa, Lukáš Doktor
On 23.08.2017 14:20, Cornelia Huck wrote:
> On Wed, 23 Aug 2017 10:35:43 +0200
> Thomas Huth <thuth@redhat.com> wrote:
>
>> True. And I just learned that you can also already set the SPEED
>> variable to either "quick" or "slow" and that we're already using
>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>> the framework for running quick vs. thorough tests is already there ...
>> we just might want to add this to some more tests, I guess...
>>
>> Question for the maintainers and the test automation folks: Is anybody
>> already running "make check SPEED=slow" or is this just rather an
>> unheard-of way of running the tests?
>
> So I tried this on master just for fun, and 'make V=1 SPEED=slow
> check-qtest-x86_64' promptly failed for some ivshmem test.
>
> On x86_86:
> TEST: tests/ivshmem-test... (pid=3672)
> /x86_64/ivshmem/single: OK
> /x86_64/ivshmem/hotplug: OK
> /x86_64/ivshmem/memdev: OK
> /x86_64/ivshmem/pair: OK
> /x86_64/ivshmem/server-msi: **
> ERROR:/home/cohuck/git/qemu/tests/ivshmem-test.c:367:test_ivshmem_server: assertion failed (ret == 0): (1 == 0)
> FAIL
> GTester: last random seed: R02Scde8fd6835fdf17450c73e2f74f25007
> (pid=3697)
> /x86_64/ivshmem/server-irq: OK
> FAIL: tests/ivshmem-test
Bisecting this problem automatically ("git bisect run" rules!) revealed
that this test broke with this commit:
commit b4ba67d9a702507793c2724e56f98e9b0f7be02b
Author: David Gibson <david@gibson.dropbear.id.au>
Title: libqos: Change PCI accessors to take opaque BAR handle
David, any ideas what's going wrong here?
Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [Qemu-devel] make check speed
2017-08-29 16:34 ` Thomas Huth
@ 2017-08-29 17:13 ` Thomas Huth
0 siblings, 0 replies; 38+ messages in thread
From: Thomas Huth @ 2017-08-29 17:13 UTC (permalink / raw)
To: Cornelia Huck, David Gibson
Cc: Laurent Vivier, Peter Maydell, Fam Zheng, Michael S. Tsirkin,
Richard Henderson, QEMU Developers, Philippe Mathieu-Daudé,
Cleber Rosa, Paolo Bonzini, Lukáš Doktor,
Alex Bennée
On 29.08.2017 18:34, Thomas Huth wrote:
> On 23.08.2017 14:20, Cornelia Huck wrote:
>> On Wed, 23 Aug 2017 10:35:43 +0200
>> Thomas Huth <thuth@redhat.com> wrote:
>>
>>> True. And I just learned that you can also already set the SPEED
>>> variable to either "quick" or "slow" and that we're already using
>>> g_test_quick() and g_test_slow() in a couple of places to check this. So
>>> the framework for running quick vs. thorough tests is already there ...
>>> we just might want to add this to some more tests, I guess...
>>>
>>> Question for the maintainers and the test automation folks: Is anybody
>>> already running "make check SPEED=slow" or is this just rather an
>>> unheard-of way of running the tests?
>>
>> So I tried this on master just for fun, and 'make V=1 SPEED=slow
>> check-qtest-x86_64' promptly failed for some ivshmem test.
>>
>> On x86_86:
>> TEST: tests/ivshmem-test... (pid=3672)
>> /x86_64/ivshmem/single: OK
>> /x86_64/ivshmem/hotplug: OK
>> /x86_64/ivshmem/memdev: OK
>> /x86_64/ivshmem/pair: OK
>> /x86_64/ivshmem/server-msi: **
>> ERROR:/home/cohuck/git/qemu/tests/ivshmem-test.c:367:test_ivshmem_server: assertion failed (ret == 0): (1 == 0)
>> FAIL
>> GTester: last random seed: R02Scde8fd6835fdf17450c73e2f74f25007
>> (pid=3697)
>> /x86_64/ivshmem/server-irq: OK
>> FAIL: tests/ivshmem-test
>
> Bisecting this problem automatically ("git bisect run" rules!) revealed
> that this test broke with this commit:
>
> commit b4ba67d9a702507793c2724e56f98e9b0f7be02b
> Author: David Gibson <david@gibson.dropbear.id.au>
> Title: libqos: Change PCI accessors to take opaque BAR handle
>
> David, any ideas what's going wrong here?
Never mind, I've found the problem: dev->msix_pba_bar is not properly
initialized anymore if bir_pba == bir_table. I'm working on a patch...
Thomas
^ permalink raw reply [flat|nested] 38+ messages in thread