The tests igt@drv_selftest@live_sanitycheck, igt@drv_module_reload@*, hit this issue on ILK: <7> [311.456003] [drm:edp_panel_on [i915]] Turn eDP port A panel power on <7> [311.456068] [drm:wait_panel_power_cycle [i915]] Wait for panel power cycle <7> [311.456213] [drm:wait_panel_status [i915]] mask b800000f value 00000000 status 00000000 control abcd0008 <7> [311.456310] [drm:wait_panel_status [i915]] Wait complete <7> [311.456397] [drm:edp_panel_on [i915]] Wait for panel power on <7> [311.456488] [drm:wait_panel_status [i915]] mask b000000f value 80000008 status 9000000a control abcd0009 <7> [311.531334] [drm:asle_work [i915]] bclp = 0x800000ea <3> [316.458093] [drm:wait_panel_status [i915]] *ERROR* Panel status timeout: status 90000009 control abcd0009 <7> [316.458245] [drm:wait_panel_status [i915]] Wait complete
Created attachment 142516 [details] ILK dmesg logs of the test execution Full dmesg log from the execution of the test (sorry, the full logs are not available).
The power sequencer delays are as follows: > <7> [310.447602] [drm:intel_dp_init_panel_power_sequencer [i915]] panel power up delay 200, power down delay 50, power cycle delay 600 > <7> [310.447694] [drm:intel_dp_init_panel_power_sequencer [i915]] backlight on delay 1, off delay 200 > <7> [310.447792] [drm:intel_dp_init_panel_power_sequencer_registers [i915]] panel power sequencer register settings: PP_ON 0x47d00001, PP_OFF 0x1f40001, PP_DIV 0x186906 (In reply to Martin Peres from comment #0) > The tests igt@drv_selftest@live_sanitycheck, igt@drv_module_reload@*, hit > this issue on ILK: > > <7> [311.456003] [drm:edp_panel_on [i915]] Turn eDP port A panel power on > <7> [311.456068] [drm:wait_panel_power_cycle [i915]] Wait for panel power > cycle > <7> [311.456213] [drm:wait_panel_status [i915]] mask b800000f value 00000000 > status 00000000 control abcd0008 > <7> [311.456310] [drm:wait_panel_status [i915]] Wait complete Panel is now in S0.0, power cycle delay not active. > <7> [311.456397] [drm:edp_panel_on [i915]] Wait for panel power on > <7> [311.456488] [drm:wait_panel_status [i915]] mask b000000f value 80000008 > status 9000000a control abcd0009 We just turned on the panel, and it has immediately reached S1.2. > <7> [311.531334] [drm:asle_work [i915]] bclp = 0x800000ea > <3> [316.458093] [drm:wait_panel_status [i915]] *ERROR* Panel status > timeout: status 90000009 control abcd0009 > <7> [316.458245] [drm:wait_panel_status [i915]] Wait complete Timeout after five seconds and the panel has only reached S1.1. Based on the earlier information T1+T2 was 200 ms, so we should have reached this state long ago. And the T5 delay is only 100 usec so we should reach S1.0 real soon now. > <7> [316.458851] [drm:edp_panel_vdd_on [i915]] PP_STATUS: 0x90000009 PP_CONTROL: 0xabcd000b 600 usec elapsed, and we're still in S1.1. So feels like the state machine is making progress, but much slower than expected. PP_DIV 0x186906 is consistent with the rawclk readout > <7> [310.440356] [drm:i915_driver_load [i915]] rawclk rate: 125000 kHz This all looks rather strange. Maybe some clock gating w/a getting applied too late?
(In reply to Martin Peres from comment #1) > This all looks rather strange. Maybe some clock gating w/a getting applied > too late? static void ibx_init_clock_gating(struct drm_i915_private *dev_priv) { /* * On Ibex Peak and Cougar Point, we need to disable clock * gating for the panel power sequencer or it will fail to * start up when no ports are active. */ I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE); } However that should have been applied by the time the error appeared, and I can't see any potential rmw races with that register on ilk/ibx. Also this was a module reload test so the w/a would have been applied by the previous incarnation already. But the symptoms are fairly suggestive though...
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ILK: igt@runner@aborted - fail - Previous test: kms_busy (basic-flip-a) - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5449_49/fi-ilk-m540/igt@runner@aborted.html
Ville, is this failure caused due to regression?
This issue occurred 7 times out of 2042 runs. Last seen CI_DRM_5449_49 (1 month / 597 runs ago). Dropping the priority of this bug to high.
This issue last occurred 9 months/1,711 runs ago. Reproduction rate: 2/3707
(In reply to Bret Davis from comment #7) > This issue last occurred 9 months/1,711 runs ago. Reproduction rate: 2/3707 Closing and archiving the bug. Please reopen the issue if it occurs again.
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.