Created attachment 144909 [details] dmesg while reproducing the error twice Hi, I cannot get external monitors to work on my X1 gen6 on Linux (Ubuntu) when they are connected over a dock. I tried the official dock from lenovo as well as an third-party usb-c adapter. The systems immediately freezes if I hotplug an external monitor or it freezes when I try to configure the external monitor (which is not enabled in the settings up to this point). It unfreezes when the cable is disconnected. In some cases booting with the external monitor ended up at a log-in screen with reduced screen resolution (below full HD). Kernel: 5.3.0-994-generic (from here: https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2019-07-27/) However, it affects various other kernel versions as well. OS: Kubuntu 19.04 Machine: Lenovo X1 (Gen6); 20KGS03800 Display connector: HDMI and DP dmesg is attached (external monitor was connected twice after boot up) Additional info: External monitors were working on Kubuntu 18.04 earlier this year. The other day, I tried the livesystem 18.04.2 which is already affected by the bug. Please, let me know if I can provide any further information from my end or point me to any other place where I should report this bug instead. Thanks to anyone who looks into this.
IS the attached log is from drmtip? If not, can you please verity this issue with drmtip (https://cgit.freedesktop.org/drm-tip)?
I used the drm-tip kernel from the Ubuntu team. Kernel: 5.3.0-994-generic (from here: https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2019-07-27/) I just tried to compile the kernel from https://cgit.freedesktop.org/drm-tip but could not boot it afterwards. Not sure what exactly went wrong there. Is it necessary to compile the linked kernel or is the version I used sufficient/close enough?
(In reply to tmai from comment #2) > I used the drm-tip kernel from the Ubuntu team. > > Kernel: 5.3.0-994-generic > (from here: > https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2019-07-27/) > > I just tried to compile the kernel from https://cgit.freedesktop.org/drm-tip > but could not boot it afterwards. Not sure what exactly went wrong there. > > Is it necessary to compile the linked kernel or is the version I used > sufficient/close enough? It is recommended to verify the issue with https://cgit.freedesktop.org/drm-tip. In general here are the instructions to build kernel, check if that helps you. https://kernelnewbies.org/KernelBuild
Created attachment 144956 [details] dmesg with drm-tip kernel from 06-aug-2019 I finally managed to compile and boot a new kernel. I used 'make INSTALL_MOD_STRIP=1 modules_install' to reduce the initram-img and get it to boot. Before I copied the attached dmesg I booted my system, plugged in a display-port cable from my monitor and unplugged it a few seconds later after the system froze. This got it to unfreeze and let me prepare the dmesg dump.
This bug also affects fedora 30 booted from a live stick (sry, I did not compile a drm-tip kernel for that OS, too). It also is reproducible on an official Lenovo docking station and no-name usb-c dock as well. This error description on a non-lenovo machine could be related to my problem: https://bugs.freedesktop.org/show_bug.cgi?id=110629
Created attachment 145204 [details] dmesg with drm-tip kernel from 29-aug-2019 reproduced problem with hdmi and displayport cable
Created attachment 145205 [details] dmesg with drm-tip kernel from 29-aug-2019 shorter version
I created a new dmesg-dump with the drm-tip kernel 5.3.0-rc6+ Sine the last dump is now a few weeks old. Please let me know, if I can provide anything else to support your work or if I should post this bug somewhere else, additionally.
In dmesg it looks like whenever it tries to detect DP the dpcd read times out: [ 11.576987] [drm:intel_dp_detect [i915]] [CONNECTOR:92:DP-1] [ 11.585363] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.593726] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.602089] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff ... [ 11.819474] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.827834] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.836194] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.844556] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 11.844561] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 Can you boot in console mode and check how it works then? (add "3" after "drm.debug" in the kernel command line).
Created attachment 145279 [details] dmesg dump after booting to console I added the parameter 3 to boot to console which resulted in the attached dmesg_dump (I re-used the last drm-tip kernel I compiled). After attaching the monitor to the docking station I got a couple of FIFO underrun messages directly on the console. I took a photo, however, they are also reported in the dmesg dump.
(In reply to tmai from comment #10) > Created attachment 145279 [details] > dmesg dump after booting to console > > I added the parameter 3 to boot to console which resulted in the attached > dmesg_dump (I re-used the last drm-tip kernel I compiled). > > After attaching the monitor to the docking station I got a couple of FIFO > underrun messages directly on the console. I took a photo, however, they are > also reported in the dmesg dump. Did the external display show anything in console mode or the system freeze? FIFO underruns are irrelevant to the problem and can happen for short time during modeset.
No, the monitor did not show anything. More precisely, I tried two different monitors and two different cables. None worked.
(In reply to tmai from comment #12) > No, the monitor did not show anything. More precisely, I tried two different > monitors and two different cables. None worked. There might be a race condition between fbdev polling the outputs and then executing probing and usb hub discovery, because what I see in the log is that we get a hotplug event and start probing, before the usb hub is even completely discovered: 2.788336] kernel: [drm:drm_fb_helper_hotplug_event.part.0 [drm_kms_helper]] here goes fbdev hotplug event and we start probing: [ 2.788346] kernel: [drm:drm_client_modeset_probe [drm]] [ 2.788353] kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:86:eDP-1] [ 2.788378] kernel: [drm:intel_dp_detect [i915]] [CONNECTOR:86:eDP-1] [ 2.788434] kernel: [drm:intel_dp_print_rates [i915]] source rates: 162000, 216000, 270000, 324000, 432000, 540000 [ 2.788473] kernel: [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000 [ 2.788497] kernel: [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000 [ 2.788545] kernel: [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes [ 2.789155] kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 2.789168] kernel: [drm:drm_add_edid_modes [drm]] ELD: no CEA Extension found [ 2.789176] kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 2.789195] kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:86:eDP-1] probed modes : [ 2.789205] kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 60 141000 1920 1936 1952 2104 1080 1083 1097 1116 0x48 0xa here we start detecting DP-1, despite usb device discovery hasn't completed yet [ 2.789210] kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:92:DP-1] [ 2.789241] kernel: [drm:intel_dp_detect [i915]] [CONNECTOR:92:DP-1] [ 2.797582] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.805917] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.814248] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.822575] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.830902] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.839228] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.847554] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.855880] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.864206] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.872531] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.880856] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.889183] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff here USB hub is found to be connected, however we are already trying to communicate with DP-1: [ 2.889485] kernel: usb 1-3: New USB device found, idVendor=17ef, idProduct=3074, bcdDevice= 0.00 [ 2.889486] kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.889487] kernel: usb 1-3: Product: USB Billboard [ 2.889488] kernel: usb 1-3: Manufacturer: Cypress Semiconductor [ 2.889488] kernel: usb 1-3: SerialNumber: 11AD1D00B625480C19290B00 [ 2.897508] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.905834] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.914159] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.916129] kernel: tsc: Refined TSC clocksource calibration: 1991.999 MHz [ 2.916134] kernel: clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x396d4ffc055, max_idle_ns: 881590662783 ns [ 2.916144] kernel: clocksource: Switched to clocksource tsc [ 2.922510] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.930869] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.939228] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.947586] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.955945] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.964303] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.972661] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.981020] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.989379] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 2.997737] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.006096] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.014454] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.016119] kernel: usb 1-4: new high-speed USB device number 4 using xhci_hcd [ 3.016287] kernel: usb 4-2.2: new SuperSpeedPlus Gen 2 USB device number 3 using xhci_hcd [ 3.022812] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.031171] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.039011] kernel: usb 4-2.2: New USB device found, idVendor=17ef, idProduct=3070, bcdDevice= a.74 [ 3.039012] kernel: usb 4-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3.039013] kernel: usb 4-2.2: Product: USB3.1 Hub [ 3.039014] kernel: usb 4-2.2: Manufacturer: VIA Labs, Inc. [ 3.039531] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.041652] kernel: hub 4-2.2:1.0: USB hub found [ 3.041953] kernel: hub 4-2.2:1.0: 4 ports detected [ 3.047897] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.056260] kernel: [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff [ 3.056266] kernel: [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 [ 3.056270] kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:92:DP-1] disconnected In normal situation, at least on my desktop it looks completely different - first we get USB hub discovered, then hotplug event and then we start probing. Have no clue currently how to fix that, however may be adding some artificial delay, before doing actual probing might help and confirm that idea. I will attach some patch soon, once I figure out what can be done.
Created attachment 145373 [details] [review] Experimental patch to check if this is a race condition when USB dock is plugged
(In reply to tmai from comment #12) > No, the monitor did not show anything. More precisely, I tried two different > monitors and two different cables. None worked. Please test if possible with the patch above, I see that intel_dp_detect is called simultaneously with usb hub being set up, which might result in some kind of race condition.
Created attachment 145392 [details] dmesg with drm-tip kernel from 16-sep-2019 with patch, booted to console, noname usb-c dock
Created attachment 145393 [details] dmesg with drm-tip kernel from 16-sep-2019 with patch, booted to console, lenovo dock
Created attachment 145394 [details] dmesg with drm-tip kernel from 16-sep-2019 with patch, booted to gui (kde), lenovo dock
First of all, thanks for the patch and all the explaining. I am learning a few things here. :-) I attached 3 new dmesg files. All were created with a fresh drm-tip kernel + patch. A brief description of the results: 1. Test with noname-dock booted to console: The Monitor (via hdmi cable) was connected at a 1024xsomething resolution. Besides the low resolution everything seemed to work fine. Afterwards I rebooted to gui (kde). Same result, monitor was connected, but with a low resolution. I could not change the resolution via the kde settings menu. 2. Test with lenovo-dock booted to console: No change here. Still no connection to the monitor(s). I tried to monitors with two cables (hdmi and dp). The hdmi-monitor works fine when connected directly to the notebook. After playing around a little the system eventually crashed. I had to reboot with a hard shutdown. 3. Test with lenovo-dock booted to gui (kde): Same thing as with the console: no monitor worked via the dock. However, I noticed that the hdmi monitor connected to the laptop directly still showed a screen, when I connected the other monitor as via dp at the dock. In that scenario the laptop screen itself went dark, but still showed the mouse cursor.
(In reply to tmai from comment #19) > First of all, thanks for the patch and all the explaining. I am learning a > few things here. :-) > > I attached 3 new dmesg files. All were created with a fresh drm-tip kernel + > patch. > > A brief description of the results: > > 1. Test with noname-dock booted to console: The Monitor (via hdmi cable) was > connected at a 1024xsomething resolution. Besides the low resolution > everything seemed to work fine. Afterwards I rebooted to gui (kde). Same > result, monitor was connected, but with a low resolution. I could not change > the resolution via the kde settings menu. > > 2. Test with lenovo-dock booted to console: No change here. Still no > connection to the monitor(s). I tried to monitors with two cables (hdmi and > dp). The hdmi-monitor works fine when connected directly to the notebook. > After playing around a little the system eventually crashed. I had to reboot > with a hard shutdown. > > 3. Test with lenovo-dock booted to gui (kde): Same thing as with the > console: no monitor worked via the dock. However, I noticed that the hdmi > monitor connected to the laptop directly still showed a screen, when I > connected the other monitor as via dp at the dock. In that scenario the > laptop screen itself went dark, but still showed the mouse cursor. In 2) from dmesg I see constantly repeating pattern: [ 204.218230] [drm:intel_get_hpd_pins.isra.10 [i915]] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020, long 0x00000000 [ 204.218245] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - short [ 204.224610] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 07000000 [ 204.224628] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 2 [ 204.224644] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0 [ 204.242876] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 07000000 [ 204.242892] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 2 [ 204.242908] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0 [ 204.261150] [drm:intel_dp_dump_link_status [i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x22 adj_req2_3:0x22 [ 204.261166] [drm:intel_dp_start_link_train [i915]] Clock recovery check failed, cannot continue channel equalization [ 204.261813] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:92:DP-1] Link Training failed at link rate = 540000, lane count = 4 That obviously explains why it didn't work at least for 2) However in 1) and 3) there is no such thing, which is a bit strange as in 3) you have same hardware except you into gui.
-- 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/352.
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.