https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4740/shard-apl8/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4741/shard-kbl4/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5262/shard-kbl3/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html Starting subtest: multiplane-rotation-cropping-top (kms_rotation_crc:1494) igt_debugfs-CRITICAL: Test assertion failure function igt_assert_crc_equal, file ../lib/igt_debugfs.c:419: (kms_rotation_crc:1494) igt_debugfs-CRITICAL: Failed assertion: !mismatch Subtest multiplane-rotation-cropping-top failed. <3> [178.694404] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
These tests were introduced in IGT_4738 (https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/14c1b132c8f829637c55fb071a9a2e5ce00e7ed8) and started failing inconsistently on KBL, and APL.
I did see KBL failing consistently while developing this test. There are three multiplane rotation tests, cropping top, no cropping and cropping bottom. Interesting thing here is only cropping top fails. Those planes are in failing test positioned so primary plane is cropped at top left corner and sprite plane is cropped at top right corner so that only about 1/4 of planes are visible on screen. For testing purpose what really fails there one could first move those planes for example so only vertical cropping happen and see if it still fails. Just my thoughts.
(In reply to Juha-Pekka Heikkilä from comment #2) > I did see KBL failing consistently while developing this test. There are > three multiplane rotation tests, cropping top, no cropping and cropping > bottom. Interesting thing here is only cropping top fails. > > Those planes are in failing test positioned so primary plane is cropped at > top left corner and sprite plane is cropped at top right corner so that only > about 1/4 of planes are visible on screen. > > For testing purpose what really fails there one could first move those > planes for example so only vertical cropping happen and see if it still > fails. Just my thoughts. Thanks for the comment. Feel free to use the trybot to further analyze the failure :)
Bug assessment: 9 months ago this test was consistently failing for both APL and KBL on almost every run. Since then, it has failed about 3 times on KBL, with the last failure on KBL 4 months ago. @Juha-Pekka Heikkilä do you think anything might have changed which could have fixed this issue? (From the initial sighting, because it looked like a data mismatch, it looked like this might have been a HW issue, though not sure).
(In reply to ashutosh.dixit from comment #4) > Bug assessment: 9 months ago this test was consistently failing for both APL > and KBL on almost every run. Since then, it has failed about 3 times on KBL, > with the last failure on KBL 4 months ago. @Juha-Pekka Heikkilä do you think > anything might have changed which could have fixed this issue? > > (From the initial sighting, because it looked like a data mismatch, it > looked like this might have been a HW issue, though not sure). When I was looking for reason why this happen I get gut feeling this was timing issue relating to planar YUV together with RGB565 on screen where it sometimes would have been said planes are ready to be shown on screen when they were still being created. I did look at PRMs for hints about this but I never found any. With this reasoning it would go along this bug is more rare now as recently primary and sprite planes handling was unified (by Ville?) from Gen9 onward.
Thanks @Juha-Pekka Heikkilä, I'd say if the occurrence of this bug is as infrequent as it seems to be now (indeed looks like an infrequent timing issue), we can reduce the severity to medium/low. Let's keep watching and perhaps do this a little bit down the line in a future assessment. Thanks!
(In reply to ashutosh.dixit from comment #6) > Thanks @Juha-Pekka Heikkilä, I'd say if the occurrence of this bug is as > infrequent as it seems to be now (indeed looks like an infrequent timing > issue), we can reduce the severity to medium/low. Let's keep watching and > perhaps do this a little bit down the line in a future assessment. Thanks! The reproduction rate of this issue is once in 4.5 drmtip runs. Last seen on drmtip_314 (4 months, 1 week old) and current ru is 394. Closing and archiving the issue. Please reopen the issue if seen again.
The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.