| Summary: | [ILK][BAT] kms_pipe_crc_basic/nonblocking-crc-pipe-b underrun Dmesg Warnings | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Akash Goel <akash.goels> |
| Component: | DRM/Intel | Assignee: | Ville Syrjala <ville.syrjala> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | highest | CC: | akash.goels, intel-gfx-bugs |
| Version: | DRI git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | ILK | i915 features: | display/Other, display/watermark |
I had though I fixed all the ILK underruns (well, all the ones not related to cursor watermarks and/or sprite scaling which can still cause genuine underruns easily), but now they seem to be back. So I suspect we have a regression on our hands. Either that or it's due to eg. a hardware change. Looking at the long term history for ilk-650, the first occurance seems to be at CI_DRM_1688, but since the problem seems fairly sporadic, I can't be sure it doesn't go further back. We have no results going back much further than that. Though in recent times (maybe since CI_DRM_1706, or thereabouts) we seem to have even more of these. kms_pipe_crc_basic seems the most prominent offender here, but it looks like kms_busy and drv_module_reload_basic have also hit these. OK, so at leas some of these seem to spurious underruns caused by link retraining: [ 424.719905] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:40:DP-1] [ 424.719939] [drm:intel_dp_detect [i915]] [CONNECTOR:40:DP-1] [ 424.720429] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 0a 84 01 01 00 01 00 02 02 06 00 00 00 00 [ 424.720769] [drm:intel_dp_detect [i915]] Display Port TPS3 support: source no, sink no [ 424.720787] [drm:intel_dp_print_rates [i915]] source rates: 162000, 270000 [ 424.720803] [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000 [ 424.720819] [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000 [ 424.721438] [drm:intel_dp_check_link_status [i915]] DP C: channel EQ not ok, retraining [ 424.721802] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 00000000 [ 424.721818] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 0 [ 424.721834] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0 [ 424.721851] [drm:intel_dp_program_link_training_pattern [i915]] Using DP training pattern TPS1 [ 424.722556] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 02000000 [ 424.722601] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 1 [ 424.722642] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0 [ 424.723391] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 04000000 [ 424.723435] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 2 [ 424.723477] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0 [ 424.724197] [drm:intel_dp_start_link_train [i915]] Max Voltage Swing reached [ 424.724241] [drm:intel_dp_program_link_training_pattern [i915]] Using DP training pattern TPS2 [ 424.725273] [drm:intel_dp_dump_link_status [i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x77 adj_req2_3:0x77 [ 424.725316] [drm:intel_dp_start_link_train [i915]] Clock recovery check failed, cannot continue channel equalization [ 424.725915] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun [ 424.726056] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun [ 424.726217] [drm:drm_edid_to_eld] ELD monitor LEN LT2452pwC [ 424.726220] [drm:drm_edid_to_eld] ELD size 36, SAD count 1 I'm going to see about just suppressing those. There are a few PCH underruns visible at the end of modesets as well though. Those may or may not be spurious. One observation I can make is that the monitor in question has audio support, so it might be we really need to add those spec mandated vblank waits to the audio enable path. I just never was able to reproduce such issues on my machines, and so I didn't find any benefit from adding them. As reference, Ville'spatchset linked to comment #2 is posted here: https://lists.freedesktop.org/archives/intel-gfx/2016-October/108662.html Jari, can we close this? Not seen on CI lately? Jari, seen once now lately https://intel-gfx-ci.01.org/CI/fi-ilk-650.html PCH: [ 364.437813] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun [ 364.454564] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Are we good enough? One we could check if we see on patchwork runs? Nog again on pw run: https://intel-gfx-ci.01.org/CI/Patchwork_3104/ *ERROR* PCH transcoder B FIFO underrun https://intel-gfx-ci.01.org/CI/Patchwork_3112/ => *ERROR* PCH transcoder B FIFO underrun Seen now last time 1st of Dec on CI. Lets follow for a while now. Marking this Resolved+Fixed, no failures on CI_DRM or Patchwork CI Testing after 2016-12-01 (https://intel-gfx-ci.01.org/CI/CI_DRM_1897/ and https://intel-gfx-ci.01.org/CI/Patchwork_3164). Reporter, ok to close? |
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.
According to e-mail results, for the CI run /archive/results/CI_IGT_test/Patchwork_2708/, there were Warning messages for the following Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> DMESG-WARN (fi-ilk-650) [ 465.200069] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun [ 465.200137] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun The patch https://patchwork.freedesktop.org/patch/115578/, which was actually tested, has no apparent connection with the above Warning messages and shouldn't have caused this issue.