Created attachment 138193 [details] /sys/kernel/debug/dri/0/i915_display_info I have Lenovo X1 Carbon laptop from 2014 with the following CPU: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz lspci reports GPU as VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) I'm on Gentoo Linux with kernel 4.15.9-gentoo, xorg-server 1.19.5, libdrm 2.4.91 and mesa 18.0.0_rc4. I'm using modesetting driver without xf86-video-intel. As my laptop has only mini displayport output, I'm trying to use DP-to-HDMI/VGA/DVI converter I got from AliExpress. Sometimes when I plug in the converter and enable the monitor with xrandr it works fine, but most of the time I see the output in xrandr, but when I enable it, monitor does not show anything. I have this in dmesg: [15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid: [ +0,000004] [00] BAD 00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00 [ +0,000001] [00] BAD 0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27 [ +0,000001] [00] BAD 0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80 [ +0,000001] [00] BAD a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c [ +0,000001] [00] BAD 45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44 [ +0,000001] [00] BAD 30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32 [ +0,000001] [00] BAD 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff [ +0,000001] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ +0,108525] i2c i2c-4: sendbytes: NAK bailout. [ +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44 [ +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44 I googled and found bug 92685 and tried kernel patch from there (https://patchwork.freedesktop.org/patch/195306/), but it did not change anything for me. Attaching i915_display_info and full dmesg, but without drm.debug=0xe yet.
Created attachment 138194 [details] dmesg
(In reply to Maxim from comment #0) > Created attachment 138193 [details] > /sys/kernel/debug/dri/0/i915_display_info > > I have Lenovo X1 Carbon laptop from 2014 with the following CPU: > > Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz I have a similar carbon and no real issues with any DP++ dongle I've tested. > [15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid: > [ +0,000004] [00] BAD 00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00 > [ +0,000001] [00] BAD 0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27 > [ +0,000001] [00] BAD 0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80 > [ +0,000001] [00] BAD a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c > [ +0,000001] [00] BAD 45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44 > [ +0,000001] [00] BAD 30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32 > [ +0,000001] [00] BAD 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff > [ +0,000001] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > [ +0,108525] i2c i2c-4: sendbytes: NAK bailout. So it failed even with bit banging :( > [ +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode > adaptor ID 44 > [ +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode > adaptor ID 44 And the dongle itself is returning garbage when we try to access its registers, so the problem is not limited to the ddc passthrough. One thing you may want to try is slow down the i2c bus further. We use 100kHz by default, and you may want to try something like 10kHz instead. --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -127,7 +127,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv, /* Intel GPIO access functions */ -#define I2C_RISEFALL_TIME 10 +#define I2C_RISEFALL_TIME 100
Created attachment 138229 [details] dmesg with 10kHz patch Hi. I tried the patch you gave me and it seems to work, but I can't be sure yet. I tried disconnecting adapter from laptop and HDMI from adapter in different orders and each time I'm able to enable HDMI output to my TV. I'll check this with the monitor at my work on the next week. I've also enabled drm.debug=0xe and noticed some errors and timeouts in dmesg. Attaching it just in case.
Hi again. Unfortunately, I still have issues with this. I have image on the monitor, but it goes black every couple of seconds or so for a second, thus impossible to work with. I have such lines in dmesg: [266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f [266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110 [266394.637266] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:72:DP-1] disconnected Can this be fixed or this adapter is impossible to work with?
(In reply to Maxim from comment #4) > Hi again. Unfortunately, I still have issues with this. I have image on the > monitor, but it goes black every couple of seconds or so for a second, thus > impossible to work with. I have such lines in dmesg: > > [266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f > [266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First > error: -110 > [266394.637266] [drm:drm_helper_probe_single_connector_modes] > [CONNECTOR:72:DP-1] disconnected Those aren't directly related to the blinking. These are in fact normal messages one would expect during hotplug processing. However they may be a symptom of the dongle failing somehow and wiggling the hotplug line. > > Can this be fixed or this adapter is impossible to work with? Can you do: dmesg -C wait until the display blink has happened a couple of times dmesg and attach the log from dmesg.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Created attachment 138693 [details] new dmesg Sadly, the problem continues. I came to work once again and tried to connect my monitor, but this time it won't show the image at all. xrandr sees the monitor and can set mode, but nothing happens after it. Judging by dmesg, kernel recognizes monitor, as it prints its model. What can be wrong now? Attaching dmesg after reboot just in case.
(In reply to Maxim from comment #7) > Created attachment 138693 [details] > new dmesg > > Sadly, the problem continues. I came to work once again and tried to connect > my monitor, but this time it won't show the image at all. xrandr sees the > monitor and can set mode, but nothing happens after it. Judging by dmesg, > kernel recognizes monitor, as it prints its model. What can be wrong now? > Attaching dmesg after reboot just in case. Actually, ignore that. It seems that I forgot to switch input on monitor... Sorry :)
So solved or still issue?
Created attachment 138723 [details] dmesg after flicker (In reply to Ville Syrjala from comment #5) > Can you do: > > dmesg -C > wait until the display blink has happened a couple of times > dmesg > > and attach the log from dmesg. Okay, so I did as you said. Here's dmesg right after display went black two times.
(In reply to Maxim from comment #10) > Created attachment 138723 [details] > dmesg after flicker > > (In reply to Ville Syrjala from comment #5) > > Can you do: > > > > dmesg -C > > wait until the display blink has happened a couple of times > > dmesg > > > > and attach the log from dmesg. > > Okay, so I did as you said. Here's dmesg right after display went black two > times. Nothing particularly interesting in the log. There is a normal looking disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly the display was just blanked for that period of time?). Also a ton of some ASLE junk but presumably that should be harmless. Given the evidence we have I'd lean towards the DP++ dongle simply being garbage.
(In reply to Ville Syrjala from comment #11) > (In reply to Maxim from comment #10) > > Nothing particularly interesting in the log. There is a normal looking > disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly > the display was just blanked for that period of time?). Also a ton of some > ASLE junk but presumably that should be harmless. > > Given the evidence we have I'd lean towards the DP++ dongle simply being > garbage. Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you going to commit it or at least make configurable?
Ville, what was next step, is this invalid issue?
(In reply to Maxim from comment #12) > (In reply to Ville Syrjala from comment #11) > > (In reply to Maxim from comment #10) > > > > Nothing particularly interesting in the log. There is a normal looking > > disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly > > the display was just blanked for that period of time?). Also a ton of some > > ASLE junk but presumably that should be harmless. > > > > Given the evidence we have I'd lean towards the DP++ dongle simply being > > garbage. > > Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you > going to commit it or at least make configurable? We definitely don't want to put that patch in as is since it'll slow down things for everyone. Making it configurable is an option I suppose. Possibly a better option would be to introduce some kind of fallback mechanism where we try to reduce the i2c bus speed when encountering errors. We might want something like that for DDC/CI as well. Or at least I have one monitor here where the DDC/CI isn't happy with the 100KHz speed either.
Reducing the priority to low based on the impact and the workaround.
The folks over at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849484 are saying they think that bug is the same as this one, but I don't think it is. What do you think?
You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.
-- 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/91.
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.