On 7/1/20 6:43 PM, Alex Bennée wrote:
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
On 7/1/20 3:56 PM, Alex Bennée wrote:
For some reason these tests fail all the time on GitLab. I can
re-create the hang around 3% of the time locally but it doesn't seem
to be MTTCG related. For now skipIf on GITLAB_CI.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
---
tests/acceptance/machine_mips_malta.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/acceptance/machine_mips_malta.py
b/tests/acceptance/machine_mips_malta.py
index 92b4f28a112..7c9a4ee4d2d 100644
--- a/tests/acceptance/machine_mips_malta.py
+++ b/tests/acceptance/machine_mips_malta.py
@@ -15,6 +15,7 @@ from avocado import skipUnless
from avocado_qemu import Test
from avocado_qemu import wait_for_console_pattern
from avocado.utils import archive
+from avocado import skipIf
NUMPY_AVAILABLE = True
@@ -99,6 +100,7 @@ class MaltaMachineFramebuffer(Test):
"""
self.do_test_i6400_framebuffer_logo(1)
So the test works using a single core...
Good we have a test to figure the bug!
It's about a 1-3% failure rate on my big test box but hits every time on
CI. However I did disable MTTCG and still saw failures so I think it's a
more subtle breakage than just a straight race.
I first thought it was a MTTCG problem, but then I realized you didn't
disable the single core test. When using >1 core, the malta uses a
different device, the CPS for Coherent Processing System. It contains
a Inter-Thread Communication Unit and a Global Interrupt Controller.
There might be a I/O locking problem. In particular, some of these
devices access the &cpu->env (the ITU is more of micro-architecture).
This is why I was excited by your finding :) We might have a way
to figure it out.