Created attachment 128913 [details] xorg log (hostname stripped) Hi, At some point, after upgrade, one of my displays stopped being detected. I can forcefully make it work but xrandr reports as the display not being connected (which causes some annoyances in KDE). My setup: --------- *** uname -a: Linux _____ 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux *** packages: xorg 1.19.1 xf86-video-intel 1:2.99.917+747+g028c946d-1 *** lspci: 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset Family KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4) 00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 (rev d4) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04) 02:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge *** xrandr after forcing output: Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 DP1 disconnected 2560x1440+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1920x1200 59.95 2560x1440_60.00 60.00* DP1-1 disconnected (normal left inverted right x axis y axis) DP1-8 disconnected (normal left inverted right x axis y axis) DP2 connected primary 1920x1200+2560+0 (normal left inverted right x axis y axis) 520mm x 320mm 1920x1200 59.95*+ 1920x1080 50.00 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 74.98 59.90 1280x960 60.00 1280x800 59.91 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Display setup: Two displays, one connected through DisplayPort (this one is not detected) the other connected through DisplayPort + converter to HDMI (works). Notes: 1. It used to work with old xorg driver (xf86-video-intel-1:2.99.917+730+gdad64e9-1), but occasionally the display stopped being detected. 2. I can force the output by these commands: --- start --- xrandr --newmode "2560x1440_60.00" 311.83 2560 2744 3024 3488 1440 1441 1444 1490 -HSync +Vsync xrandr --addmode DP1 2560x1440_60.00 xrandr --output DP1 --mode 1920x1200 --left-of DP2 --- end --- I tried different display set-up - the same effect, I didn't play with kernel driver as I noticed that problem doesn't exist with old version of xorg driver. Lukasz G.
Jan 09 20:09:34 r-schwarzschild kernel: [drm:intel_hdmi_detect [i915]] [CONNECTOR:59:HDMI-A-1] Jan 09 20:09:34 r-schwarzschild kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: DP-HDMI ADAPTOR\004 (err 0) Jan 09 20:09:34 r-schwarzschild kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode adaptor ID: a0 (err 0) Jan 09 20:09:34 r-schwarzschild kernel: [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 2 HDMI) detected (max TMDS clock: 300000 kHz) Jan 09 20:09:34 r-schwarzschild kernel: [drm:i915_hotplug_work_func [i915]] [CONNECTOR:59:HDMI-A-1] status updated from disconnected to connected So there we were able to read the EDID. [CONNECTOR:59:HDMI-A-1] Jan 09 20:09:42 r-schwarzschild kernel: [drm:intel_hdmi_detect [i915]] [CONNECTOR:59:HDMI-A-1] Jan 09 20:09:42 r-schwarzschild kernel: [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) Jan 09 20:09:42 r-schwarzschild kernel: [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry Jan 09 20:09:42 r-schwarzschild kernel: [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) Jan 09 20:09:42 r-schwarzschild kernel: [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb Jan 09 20:09:42 r-schwarzschild kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: DP-HDMI ADAPTOR\004 (err 0) Jan 09 20:09:42 r-schwarzschild kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode adaptor ID: a0 (err 0) Jan 09 20:09:42 r-schwarzschild kernel: [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 2 HDMI) detected (max TMDS clock: 300000 kHz) Jan 09 20:09:42 r-schwarzschild kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:59:HDMI-A-1] status updated from connected to disconnected Jan 09 20:09:42 r-schwarzschild kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:59:HDMI-A-1] disconnected but here a bit later we are again unable to read it. It's quite weird since the i2c bus seems to be fine itself since we can detect the DP dual mode chip present on the bus. My only theory is that the dual mode chip is somehow going crazy and preventing the i2c access for the EDID read from reaching the actual display.
Sorry replied to the wrong bug by accident. Please attach dmesg after booting with drm.debug=0xe passed to the kernel.
Created attachment 128925 [details] dmesg with boot with drm.debug=0xe I'm attaching the log with kernel option drm.debug=0xe
submitter provided logs, moving bug to reopen state
Something fishy with MST. [ 48.701444] [drm:drm_dp_send_link_address] link address reply: 3 [ 48.701446] [drm:drm_dp_send_link_address] port 0: input 1, pdt: 1, pn: 0, dpcd_rev: 00, mcs: 1, ddps: 1, ldps 0, sdp 0/0 [ 48.701447] [drm:drm_dp_send_link_address] port 1: input 0, pdt: 3, pn: 8, dpcd_rev: 12, mcs: 0, ddps: 1, ldps 0, sdp 1/2 [ 48.701448] [drm:drm_dp_send_link_address] port 2: input 0, pdt: 0, pn: 1, dpcd_rev: 00, mcs: 0, ddps: 0, ldps 0, sdp 0/0 So port 1 looks all correct. It claims to have a peer device type of SST sink or stream sink. the logical port numbers looks fine, and the "display device plug status" is 1 and it reports it can handle some streams. We seem to be registering the connector for it, but then we're somehow unable to detect it. I don't really see why that would happen. I think someone needs to expand the MST code debug output to make any sense of this. Also the current debug messages seem rather useless without having the spec at hand. So someone might want to improve them as well.
Hi, Just to give you some update on this - after updating to a recent kernel problem no longer present. I'm marking this as resolved, I see no point (at this time) to pursuit the root cause of this problem, but thanks for looking into it. L.
(In reply to Lukasz Goralczyk from comment #6) > Hi, > > Just to give you some update on this - after updating to a recent kernel > problem no longer present. I'm marking this as resolved, I see no point (at > this time) to pursuit the root cause of this problem, but thanks for looking > into it. > > L. thanks Lukas for your feedback
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.