On 07/15, Arkadiusz Hiler wrote:
> On Mon, Jun 22, 2020 at 01:38:26PM -0300, Melissa Wen wrote:
> > When running subtests in sequence using vkms, the beginning of CRC capture
> > process does not match the simulated vblank timing. This mismatch leads to
> > an endless busy wait and, consequently, timeout failures for the remaining
> > subtests in the test sequence. This patch sets the pace by waiting for
> > vblank before starting the CRC capture.
> >
> > Signed-off-by: Melissa Wen <
melis...@gmail.com>
>
> This one is quite interetesing. The test seems to be working just fine
> on the real hardware and causes the endless busy wait on VKMS only...
>
> DRM is bad at describing usage sequences and what's defined and what's
> undefined when it comes to behavior. We just try not to break any of the
> existing users. On top of that CRC capture is a testing/debug feature
> that doesn't have have to be stable - it's not really obvious what's the
> correct course of action here.
>
> The vblank wait won't harm anyone, especially in the context presented
> above. You have to keep in mind that other implementations of CRC
> caputring doesn't have that requirement and you will likely find more
> similar instances of this usage pattern. There may be even more of them
> introduced over time - there's no CI on VKMS (fingers crossed that this
> is going to change).
>
> Have you thought about what's easier here - making the current code work
> on the VKMS side or fixing the test? I would like to know your thoughts
> on this.
fact, the problem seems to be more linked to vkms. I mean, this problem
affect vkms in other igt tests too. So the most accurate thing is to
treat it over there.
before creating a new one.