Hi Eric,
On 2020/4/2 16:50, Auger Eric wrote:
Hi Zenghui,
On 3/30/20 12:43 PM, Zenghui Yu wrote:
Hi Eric,
On 2020/3/20 17:24, Eric Auger wrote:
Triggers LPIs through the INT command.
the test checks the LPI hits the right CPU and triggers
the right LPI intid, ie. the translation is correct.
Updates to the config table also are tested, along with inv
and invall commands.
Signed-off-by: Eric Auger <eric.auger@xxxxxxxxxx>
[...]
So I've tested this series and found that the "INT" test will sometimes
fail.
"not ok 12 - gicv3: its-migration: dev2/eventid=20 triggers LPI 8195 en
PE #3 after migration
not ok 13 - gicv3: its-migration: dev7/eventid=255 triggers LPI 8196 on
PE #2 after migration"
From logs:
"INFO: gicv3: its-migration: Migration complete
INT dev_id=2 event_id=20
INFO: gicv3: its-migration: No LPI received whereas (cpuid=3,
intid=8195) was expected
FAIL: gicv3: its-migration: dev2/eventid=20 triggers LPI 8195 en PE #3
after migration
INT dev_id=7 event_id=255
INFO: gicv3: its-migration: No LPI received whereas (cpuid=2,
intid=8196) was expected
FAIL: gicv3: its-migration: dev7/eventid=255 triggers LPI 8196 on PE #2
after migration"
+static void check_lpi_stats(const char *msg)
+{
+ bool pass = false;
+
+ mdelay(100);
After changing this to 'mdelay(1000)', the above error doesn't show up
anymore. But it sounds strange that 100ms is not enough to deliver a
single LPI. I haven't dig it further but will get back here later.
Did you find some time to investigate this issue. Changing 100 to 1000
has a huge impact on the overall test duration and I don't think it is
sensible. Could you see what is your minimal value that pass the tests?
I can reproduce this issue with a very *low* probability so I failed
to investigate it :-(. (It might because the LPI was delivered to a
busy vcpu...)
You can leave it as it is until someone else complain about it again.
Or take the similar approach as check_acked() - wait up to 5s for the
interrupt to be delivered, and bail out as soon as we see it.
Thanks,
Zenghui
