Re: [PATCH v4 05/24] Revert "replay: stop us hanging in rr_wait_io_event"

[Nicholas Piggin]

On Wed Mar 13, 2024 at 7:03 AM AEST, Alex Bennée wrote:
> "Nicholas Piggin" <npiggin@gmail.com> writes:
>
> > On Tue Mar 12, 2024 at 11:33 PM AEST, Alex Bennée wrote:
> >> Nicholas Piggin <npiggin@gmail.com> writes:
> >>
> >> > This reverts commit 1f881ea4a444ef36a8b6907b0b82be4b3af253a2.
> >> >
> >> > That commit causes reverse_debugging.py test failures, and does
> >> > not seem to solve the root cause of the problem x86-64 still
> >> > hangs in record/replay tests.
> >>
> >> I'm still finding the reverse debugging tests failing with this series.
> >
> > :(
> >
> > In gitlab CI or your own testing? What are you running exactly?
>
> My own - my mistake I didn't get a clean build because of the format
> bug.

Ah, x86_64 is working for you now? Great.

> However I'm seeing new failures:
>
>   env QEMU_TEST_FLAKY_TESTS=1 AVOCADO_TIMEOUT_EXPECTED=1 ./pyvenv/bin/avocado 
> run ./tests/avocado/reverse_debugging.py
>   Fetching asset from 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_AArch64.test_aarch64_virt
>   JOB ID     : bd4b29f7afaa24dc6e32933ea9bc5e46bbc3a5a4
>   JOB LOG    : 
> /home/alex/avocado/job-results/job-2024-03-12T20.58-bd4b29f/job.log
>    (1/5) 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc: 
> PASS (4.49 s)
>    (2/5) 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_q35: 
> PASS (4.50 s)
>    (3/5) 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_AArch64.test_aarch64_virt:
>  FAIL: Invalid PC (read ffff2d941e4d7f28 instead of ffff2d941e4d7f2c) (3.06 s)

I added a bunch of test cases that x86 has problems with for some
reason, so it skips them. Maybe aarch64 is the same. I'll take a
closer look at it.

>    (4/5) 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_pseries:
>  PASS (16.48 s)
>    (5/5) 
> ./tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv:
>  FAIL: Invalid PC (read 30020210 instead of 30020214) (2.80 s)

powernv is known flaky so that's expected for now.

Thanks,
Nick