Bug 101154 - [BAT][SKL] Test assertion failure function kmstest_dumb_create, file igt_kms.c:508 on fi-skl-6700hq
Summary: [BAT][SKL] Test assertion failure function kmstest_dumb_create, file igt_kms....
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: highest critical
Assignee: Manasi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-23 12:22 UTC by Martin Peres
Modified: 2017-07-05 07:41 UTC (History)
2 users (show)

See Also:
i915 platform: SKL
i915 features: display/DP

Attachments

Description Martin Peres 2017-05-23 12:22:32 UTC 
Starting with Patchwork_4779[1], many of the igt@kms_pipe_crc_basic starting failing with the following assertion:

(kms_pipe_crc_basic:3999) igt-kms-WARNING: connector 48/eDP-1 has no modes
(kms_pipe_crc_basic:3999) igt-kms-CRITICAL: Test assertion failure function kmstest_dumb_create, file igt_kms.c:508:
(kms_pipe_crc_basic:3999) igt-kms-CRITICAL: Failed assertion: igt_ioctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0xB2)) << 0) | ((((sizeof(struct drm_mode_create_dumb)))) << ((0+8)+8)))), (&create)) == 0
(kms_pipe_crc_basic:3999) igt-kms-CRITICAL: Last errno: 22, Invalid argument
(kms_pipe_crc_basic:3999) igt-kms-CRITICAL: error: -1 != 0
Subtest hang-read-crc-pipe-A failed.

It has since been seen on Patchwork_4783[2] and CI_DRM_2645[3].

[1] https://intel-gfx-ci.01.org/CI/Patchwork_4779/
[2] https://intel-gfx-ci.01.org/CI/Patchwork_4783/
[3] https://intel-gfx-ci.01.org/CI/fi-skl-6700hq.html
Comment 1 Chris Wilson 2017-05-23 12:34:55 UTC 
The crucial breadcrumb is perhaps

[  419.523610] [drm:intel_atomic_check [i915]] Encoder config failure
Comment 2 Chris Wilson 2017-05-23 12:48:55 UTC 
[  419.523545] [drm:intel_atomic_check [i915]] [CONNECTOR:48:eDP-1] checking for sink bpp constrains
[  419.523568] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to EDID reported max of 18
[  419.523590] [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 1 max bw 270000 pixel clock 138700KHz
[  419.523610] [drm:intel_atomic_check [i915]] Encoder config failure


Which boils down to it failing to find a suitable link:

        for (; bpp >= 6*3; bpp -= 2*3) {
                mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
                                                   bpp);

                for (clock = min_clock; clock <= max_clock; clock++) {
                        for (lane_count = min_lane_count;
                                lane_count <= max_lane_count;
                                lane_count <<= 1) {

                                link_clock = intel_dp->common_rates[clock];
                                link_avail = intel_dp_max_data_rate(link_clock,
                                                                    lane_count);

                                if (mode_rate <= link_avail) {
                                        goto found;
                                }
                        }
                }
        }

because we need 2 lanes for the panel, and the max_lane_count has been left as 1 after the link training fudging.
Comment 4 Manasi 2017-06-05 23:03:30 UTC 
Again here the basic problem is due to dp_aux_ch timeouts due to which it cannot even enable link training and our link training fallback algorithm treats that error same as the link training failure and fallsback to lower value.

[  419.157692] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.166262] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.174831] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.183401] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.191972] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.200543] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7d4003ff
[  419.200555] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110
[  419.200576] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
[  419.200597] [drm:intel_dp_start_link_train [i915]] Link Training failed at link rate = 162000, lane count = 2

@Jani how can we handle this failure?
In this case, reducing link parameters will not help since the basic error is in the aux transactions and hence it could not even start link training. So should the atomic commit just fail here?

Manasi
Comment 5 Marta Löfstedt 2017-06-13 12:53:25 UTC 
please note relation to bug 101144 and bug 101167
Comment 6 Manasi 2017-06-13 16:04:10 UTC 
I was trying to see if I could find the exact system here but looks like that it not a possibility now, what are the remote login/ssh details for that CI system?
Comment 7 Tomi Sarvela 2017-07-05 07:22:13 UTC 
This fixed the issue:
c99a259 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
Comment 8 Martin Peres 2017-07-05 07:41:55 UTC 
No need to ask QA to verify, so forcing to CLOSED.

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.