Created attachment 140328 [details] dmesg fail drm-tip Hello, The machine randomly start with black screen (there are park of this machines. Some of them work OK, some have issue and some have issue more often) after again reboot it may be Ok or may be fail and start only after 3-th time some times every restart is ok (10..20 in a row) System work and I have access over ssh According to dmesg, the eDP port can not turn on the power and switch to HDMI-A-2 [ 2.418002] [drm:intel_dp_init_panel_power_sequencer_registers [i915]] panel power sequencer register settings: PP_ON 0x87d00001, PP_OFF 0x1f40001, PP_DIV 0x270f06 [ 2.418059] [drm:edp_panel_vdd_on [i915]] Turning eDP port C VDD on [ 2.418114] [drm:edp_panel_vdd_on [i915]] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd000b [ 2.420630] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x70150064 [ 2.423130] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x70150064 ... [ 2.498094] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 [ 2.498096] [drm] failed to retrieve link info, disabling eDP -- chipset: Intel(R) Celeron(R) CPU N3060 Gigabyte Technology Co., Ltd. N3060TN-EM Intel Corporation Device 22b1 (rev 35) (prog-if 00 [VGA controller]) -- system architecture: x86_64 -- kernel: 4.10 4.16 4.18(drm-tip/2018-06-23) -- Linux distribution: Ubuntu 16.04 -- Display connector: eDP cat /sys/class/drm/card0/error - is empty On normal boot ls -l /sys/class/drm/card0/ total 0 drwxr-xr-x 5 root root 0 Jun 25 14:07 card0-DP-1 drwxr-xr-x 6 root root 0 Jun 25 14:07 card0-eDP-1 drwxr-xr-x 3 root root 0 Jun 25 14:07 card0-HDMI-A-1 ... On black screen ls -l /sys/class/drm/card0/ total 0 drwxr-xr-x 5 root root 0 Jun 25 13:04 card0-DP-1 drwxr-xr-x 3 root root 0 Jun 25 13:04 card0-HDMI-A-1 drwxr-xr-x 3 root root 0 Jun 25 13:04 card0-HDMI-A-2 ...
Created attachment 140329 [details] intel_reg_dumper on fail
Created attachment 140330 [details] vbios on fail
Created attachment 140331 [details] intel_reg_dumper on OK
Created attachment 140340 [details] Xorg on fail
Has this worked before so being regression?
Kernels older than 4.10 were not used, so there is no information about regression. I checked 4.16 and 4.18, and the problem is present I'll check older kernels.
Smells like some kind of semi-broken eDP->LVDS bridge chip again. When the display works please do a 'dd if=/dev/drm_dp_aux0 of=dpcd.dump' and attach the resulting file to this bug. It should come out 1 MiB in size.
Created attachment 140353 [details] dpcd dump on monitor OK
(In reply to Andriy Sa from comment #8) > Created attachment 140353 [details] > dpcd dump on monitor OK Absolutely nothing identifiable there :( Can you check the board to see which eDP->LVDS chip is mounted there? I would assume it's close by to the LVDS connector. I couldn't find any high res images of a N3060TN board (in fact I can't find anything really). I did find a picture of a N3160TN board but couldn't tell from that which chip it has.
From the logs it looks like the eDP panel is not turned on fully before link training and so you see the AUX timeouts. Could you test it with i915.disable_power_well=0 boot parameter? You can also tell if eDP is on if intel_digital_port_connected() is returning true at that point where you see aux timeouts. Manasi
(In reply to Ville Syrjala from comment #9) > Absolutely nothing identifiable there :( Can you check the board to see > which eDP->LVDS chip is mounted there? I would assume it's close by to the > LVDS connector. I couldn't find any high res images of a N3060TN board (in > fact I can't find anything really). I did find a picture of a N3160TN board > but couldn't tell from that which chip it has. Sorry, but it takes time to check the board. (In reply to Manasi from comment #10) > From the logs it looks like the eDP panel is not turned on fully before link > training and so you see the AUX timeouts. > Could you test it with i915.disable_power_well=0 boot parameter? i915.disable_power_well=0 did not affect the problem > You can also tell if eDP is on if intel_digital_port_connected() is > returning true at that point where you see aux timeouts. It looks like eDP is off at that point, intel_digital_port_connected() return false I add additional debug print in drivers/gpu/drm/i915/intel_dp.c; intel_dp_aux_ch() ... if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) { bool port_status = intel_digital_port_connected(dev_priv, dp_to_dig_port(intel_dp)); DRM_DEBUG_KMS("dp_aux_ch intel_digital_port_connected = %d\n", port_status); DRM_DEBUG_KMS("dp_aux_ch timeout status 0x%08x\n", status); ... on dmesg ... [ 2.333004] [drm:intel_dp_aux_ch [i915]] dp_aux_ch intel_digital_port_connected = 0 [ 2.333055] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x70150064 [ 2.335550] [drm:intel_dp_aux_ch [i915]] dp_aux_ch intel_digital_port_connected = 0 [ 2.335608] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x70150064 [ 2.335623] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 [ 2.335624] [drm] failed to retrieve link info, disabling eDP ...
Created attachment 140417 [details] dmesg black screen, i915.disable_power_well=0
Manasi, Ville attached logs are helpful to proceed further?
It could be the case of the eDP panels where the panel power sequencing delay needs to increase (increase T11/T12 delay). @Ville, @Clint any thoughts? Manasi
Created attachment 144326 [details] [review] Patch to increase the panel power sequencing delay Could you please test this patch to see if this fixes the black screen issue? This increases the panel power cycle delay so that eDP panel gets sufficient time to turn on before link training
@Andriy, any feedback with the attached patch from Manasi?
(In reply to Lakshmi from comment #16) > @Andriy, any feedback with the attached patch from Manasi? No feedback from more than one month. Dropping the priority of the bug to Medium. @Andriy, can you provide the feedback as requested?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/124.
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.