Bug 108950

Summary: [CI][SHARDS] igt@kms_rotation_crc@multiplane-rotation-cropping-top - dmesg-fail - Failed assertion: !mismatch, *ERROR* CPU pipe [ABC] FIFO underrun
Product: DRI Reporter: Martin Peres <martin.peres>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: RESOLVED WORKSFORME QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: intel-gfx-bugs, juhapekka.heikkila
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard: ReadyForDev
i915 platform: BXT, KBL i915 features: display/Other

Description Martin Peres 2018-12-05 12:47:26 UTC
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
Comment 1 Martin Peres 2018-12-05 12:49:20 UTC
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.
Comment 2 Juha-Pekka Heikkilä 2018-12-05 14:00:40 UTC
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.
Comment 3 Martin Peres 2018-12-05 14:06:21 UTC
(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 :)
Comment 4 ashutosh.dixit 2019-10-25 19:27:37 UTC
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).
Comment 5 Juha-Pekka Heikkilä 2019-10-27 19:44:36 UTC
(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.
Comment 6 ashutosh.dixit 2019-10-28 18:11:13 UTC
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!
Comment 7 Lakshmi 2019-10-29 14:42:35 UTC
(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.
Comment 8 CI Bug Log 2019-10-29 14:42:51 UTC
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.