Re: [PATCH v4 28/40] tests/acceptance: skip multicore mips_malta tests on GitLab

[Jiaxun Yang]

在 2020/7/2 1:01, Philippe Mathieu-Daudé 写道:
> 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.

FYI: This issue seems relative with the performence of host machine.

I can reproduce the issue in high frequency if I unplug my laptop from

AC adapter (it will switch to powersave governor).


So my first thought was it just because TCG runs too slow so cores failed

to respond IPI timely.


Thanks.

- Jiaxun