Summary: | [BAT][SKL] Test assertion failure function kmstest_dumb_create, file igt_kms.c:508 on fi-skl-6700hq | ||
---|---|---|---|
Product: | DRI | Reporter: | Martin Peres <martin.peres> |
Component: | DRM/Intel | Assignee: | Manasi <manasi.d.navare> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | critical | ||
Priority: | highest | CC: | intel-gfx-bugs, ricardo.vega |
Version: | DRI git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | SKL | i915 features: | display/DP |
Description
Martin Peres
2017-05-23 12:22:32 UTC
The crucial breadcrumb is perhaps [ 419.523610] [drm:intel_atomic_check [i915]] Encoder config failure [ 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. More on pw: https://intel-gfx-ci.01.org/CI/Patchwork_4814/ https://intel-gfx-ci.01.org/CI/Patchwork_4729/ 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 please note relation to bug 101144 and bug 101167 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? This fixed the issue: c99a259 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts 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.