Bug 110270

Summary: [CI][SHARDS] igt@kms_dp_dsc@basic-dsc-enable-edp - fail - Default DSC enable failed on Connector: eDP-1 Pipe: A
Product: DRI Reporter: Martin Peres <martin.peres>
Component: DRM/IntelAssignee: Manasi <manasi.d.navare>
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: arkadiusz.hiler, intel-gfx-bugs, james.ausmus, manasi.d.navare, tomi.p.sarvela
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard: ReadyForDev
i915 platform: ICL i915 features: display/Other

Description Martin Peres 2019-03-28 11:55:42 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4909/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html

Starting subtest: basic-dsc-enable-eDP
(kms_dp_dsc:2547) CRITICAL: Test assertion failure function update_display, file ../tests/kms_dp_dsc.c:192:
(kms_dp_dsc:2547) CRITICAL: Failed assertion: enabled
(kms_dp_dsc:2547) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_dp_dsc:2547) CRITICAL: Default DSC enable failed on Connector: eDP-1 Pipe: ASubtest basic-dsc-enable-eDP failed.

And while we are at it, please add a \n at the end of "Default DSC enable failed on Connector: eDP-1 Pipe: A"
Comment 2 Arek Hiler 2019-04-01 13:37:48 UTC
(In reply to Martin Peres from comment #0)
> And while we are at it, please add a \n at the end of "Default DSC enable
> failed on Connector: eDP-1 Pipe: A"

https://patchwork.freedesktop.org/series/58831/
Comment 3 Martin Peres 2019-04-01 13:38:35 UTC
We might want to improve the error reporting here, because there isn't much to go by with...

Anyway, moving to highest because of the high reproduction rate (every 4 runs in shards) and because the potential impact is users getting a black screen.

Since we are at it, we should write a test that verifies than when DSC enabling fails, we get a link status error, which would allow the userspace to recover. We'll likely need to use the chamelium for this.
Comment 4 Imre Deak 2019-04-01 14:06:54 UTC
The problem is that the test does a fastset and expects that the previous write to i915_dsc_fec_support takes effect during this fastset. This isn't the case however, the driver will only look at i915_dsc_fec_support during a full modeset. So the test should be fixed making sure it does a full modeset. Also an exit handler should be installed in the test to restore the previous value of  i915_dsc_fec_support in case things fail midway.

Adding Manasi.
Comment 5 Manasi 2019-04-01 16:08:52 UTC
So to ensure a full modeset, the test should force a modeset with 0 first and then with the preferred mode with DSC enable so that it does a full modeset, correct?
That should fix it?

Manasi
Comment 6 Manasi 2019-04-02 00:49:29 UTC
In the past, I have called ret = drmModeSetCrtc(drm_fd, c->crtc, 0, 0, 0,
                                     NULL, 0, NULL); to set the mode to NULL to clear all states and then igt_display_commit(), with the actual mode so that it triggers a full modeset.
Imre, do you know how I can do the same using the igt wrappers?

Manasi
Comment 7 Imre Deak 2019-04-02 09:46:40 UTC
(In reply to Manasi from comment #6)
> In the past, I have called ret = drmModeSetCrtc(drm_fd, c->crtc, 0, 0, 0,
>                                      NULL, 0, NULL); to set the mode to NULL
> to clear all states and then igt_display_commit(), with the actual mode so
> that it triggers a full modeset.
> Imre, do you know how I can do the same using the igt wrappers?
> 
> Manasi

Calling

igt_output_set_pipe(output, PIPE_NONE);

before the commit should disable the output.
Comment 8 Manasi 2019-04-02 16:15:05 UTC
Ok, i will add that before calling igt_display_commit(), that should force a full modeset. Will submit a patch today.

Regards
Manasi
Comment 9 Arek Hiler 2019-04-08 11:22:35 UTC
Seems like we hit this issue only on iclb2. The other shards skip it. That explains ~10% reproduction, as shards get executed on the pool randomly.

Seems like iclb2 panel is different (but that doesn't mean is bad!) and it's the only one that supports DSC. We have to change that, if possible, to make the shards more consistent.

This would be a perfect candidate for targeted testing farm (https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/25).

As of Manasi's patch (https://patchwork.freedesktop.org/series/58887/), it haven't got executed on ICL shards due to limited machine availability, and even if we did it would be just 10% chance of hitting the right machine, so we don't know whether it fixes anything.

Seems like it will need some manual verification from me once the farm is quite.
Comment 10 Martin Peres 2019-04-08 11:42:27 UTC
*** Bug 109358 has been marked as a duplicate of this bug. ***
Comment 11 James Ausmus 2019-04-08 22:49:26 UTC
No user impact here - the problem is purely an issue with how the IGT test is triggering forcing of turning DSC on/off. Lowering priority to match
Comment 12 Lakshmi 2019-04-10 11:00:11 UTC
Tomi, ICLb2 supports DSC? If so, can we change it to make all shard machines consistent?
Comment 13 CI Bug Log 2019-04-10 12:41:46 UTC
A CI Bug Log filter associated to this bug has been updated:

{- ICL: igt@kms_dp_dsc@basic-dsc-enable-edp - fail - Failed assertion: enabled, Last errno: 25, Inappropriate ioctl for device, Default DSC enable failed on Connector: eDP-1 Pipe: A -}
{+ ICL: igt@kms_dp_dsc@basic-dsc-enable-edp - fail - Failed assertion: enabled, (Last errno: 25, Inappropriate ioctl for device)?, Default DSC enable failed on Connector: eDP-1 Pipe: A +}

 No new failures caught with the new filter
Comment 14 Manasi 2019-04-10 18:25:07 UTC
Patches that should fix this issue have been merged
Comment 15 Martin Peres 2019-04-17 14:24:06 UTC
(In reply to Manasi from comment #14)
> Patches that should fix this issue have been merged

The fix got merged in IGT_4942, and it went from failing 100% of the time on shard-iclb2 to passing all the time. Thanks!
Comment 16 CI Bug Log 2019-04-17 14:24:14 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.