This is a meta bug to gather all KMS bugs that are filed on CRC mismatches.
A high number of kms tests on many machines has been flip-flopping on CRC mismatch for a long time. This makes us question if the CRC functionality is working and/or is used in the correct manner. If we still want so many KMS test to based on a CRC comparison, we need to come up with a way to verify the CRC functionality itself.
[ 249.764040] [drm:drm_crtc_add_crc_entry] *ERROR* Overflow of CRC buffer, userspace reads too slow.
maybe a hint for GLK and SKL.
Moving to high priority since there is an owner following this
(In reply to Marta Löfstedt from comment #1)
> bug 102614
> [ 249.764040] [drm:drm_crtc_add_crc_entry] *ERROR* Overflow of CRC buffer,
> userspace reads too slow.
> maybe a hint for GLK and SKL.
I have noticed the above overflow error message even on BYT. I think this is the reason for this overflow message: IGT tests that read CRC data usually start CRC generation, read CRC data, stop CRC generation and validate the CRC data. Some tests are validating the CRC data even before stopping the CRC generation. If validating the CRC data results in a mismatch and therefore an assert, the test may quit without stopping the CRC generation. This can cause the CRC buffer to get filled up and the overflow error message shows up.
For example, here are few lines from tests/kms_pipe_crc_basic.c test which I think is the correct order - crc is stopped before validating the CRC data. But there are some tests which validate the CRC data before stopping the CRC. For example, in tests/kms_rotation_crc.c test_plane_rotation(), CRC data is validated before stopping the CRC.
From: from tests/kms_pipe_crc_basic.c:
pipe_crc = igt_pipe_crc_new(data->drm_fd, pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
n_crcs = igt_pipe_crc_get_crcs(pipe_crc, N_CRCS, &crcs);
/* and ensure that they'are all equal, we haven't changed the fb */
for (j = 0; j < (n_crcs - 1); j++)
igt_assert_crc_equal(&crcs[j], &crcs[j + 1]);