Bug 111480 - i915 monitor connected through dock not working
Summary: i915 monitor connected through dock not working
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: highest critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-24 13:35 UTC by Joseph Thommes
Modified: 2019-10-10 15:30 UTC (History)
2 users (show)

See Also:
i915 platform: CFL
i915 features: display/HDMI


Attachments
dmesg connecting dock with monitor and activating it (247.35 KB, text/plain)
2019-08-24 13:35 UTC, Joseph Thommes
no flags Details
dmesg booting connected with dock (beginnig missing) (1015.20 KB, text/plain)
2019-08-24 13:37 UTC, Joseph Thommes
no flags Details
end of dmesg after drm stopped spamming the log (1007.42 KB, text/plain)
2019-08-24 13:38 UTC, Joseph Thommes
no flags Details
dmesg_drm2 (17.07 MB, text/plain)
2019-08-28 10:39 UTC, Joseph Thommes
no flags Details
dmesg_drm3 (25.38 MB, text/plain)
2019-08-28 10:40 UTC, Joseph Thommes
no flags Details
i915_display_info (5.02 KB, text/plain)
2019-08-28 10:41 UTC, Joseph Thommes
no flags Details
xrandr_output (1.69 KB, text/plain)
2019-08-28 10:41 UTC, Joseph Thommes
no flags Details
Complete log with monitor attached (51.32 MB, text/plain)
2019-10-07 19:43 UTC, Joseph Thommes
no flags Details
dmesg_drm_debug=0xe (17.95 MB, text/plain)
2019-10-10 14:25 UTC, Joseph Thommes
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Thommes 2019-08-24 13:35:29 UTC
Created attachment 145148 [details]
dmesg connecting dock with monitor and activating it

Bug description:

Monitor connected through HDMI or DP in lenovo-thunderbolt dock causes
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
and after some time
[drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
if enabled in xserver. Just connecting and not using it doesn't do anything.

The monitor shows up as a DP-Monitor even if it is connected through HDMI.
Also my input becomes extremely laggy, windows do not respond and my fan spins up (not sure if this is related). I do not get any output on the screen, but resolution etc are determined correctly when checking in xrandr.
After unplugging the monitor, everything is back to normal.

The monitor works with other computers.
All available firmware updates (dock and laptop) have been installed.

System environment:
-- chipset: not sure how to determine
-- system architecture: 64-bit
-- xf86-video-intel: 1:2.99.917+870+g6f4972d5-1
-- xserver: 1.20.5-2
-- mesa: 19.1.4-1
-- libdrm: 2.4.99-1
-- kernel: 5.2.9-arch1-1-ARCH
-- Linux distribution: arch
-- Machine or mobo model: Lenovo Thinkpad T490 (20N2), Ultra Docking Station Type 40AJ
-- Display connector: HDMI/DP through dock

Reproducing steps:
Power up the laptop and login.
Connect the dock with a Monitor plugged in. (HDMI)
Activate the second screen (with arandr).

Alternative:
Boot with dock and monitor connected and start an X session.

Additional info:
None
Comment 1 Joseph Thommes 2019-08-24 13:37:20 UTC
Created attachment 145149 [details]
dmesg booting connected with dock (beginnig missing)
Comment 2 Joseph Thommes 2019-08-24 13:38:21 UTC
Created attachment 145150 [details]
end of dmesg after drm stopped spamming the log
Comment 3 Joseph Thommes 2019-08-24 13:39:05 UTC
Let me know if I can do anything more or if additional information is needed.
Comment 4 Lakshmi 2019-08-26 07:26:44 UTC
From "dmesg connecting dock with monitor and activating it " I couldn't find any errors/failures indicating a kernel issue.


From "dmesg booting connected with dock (beginnig missing)" even though the log is not from boot I notice that 
24.879406] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:99:DP-2] Link Training failed at link rate = 540000, lane count = 4

From "end of dmesg after drm stopped spamming the log " 
[  374.881814] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
[  374.881962] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:99:DP-2] Link Training failed at link rate = 162000, lane count = 2

Can you please verify the issue with drmtip (https://cgit.freedesktop.org/drm-tip)? Please attach the full dmesg log from boot if the problem persists with drmtip.

Also when the issue occurred can you attach display info
cat /sys/kernel/debug/dri/0/i915_display_info
Comment 5 Joseph Thommes 2019-08-28 10:38:55 UTC
Ok, sorry that this took so long, but I finally had time.
So what I did is booting with the dock attached and the monitor connected through the HDMI port.
After this I logged into a tty and did:
dmesg > dmesg_drm*
then dmesg -w >> dmesg_drm*
After this I waited a bit and logged into another tty which starts an X server.
And I just switched a bit between the X server and the tty.
In one case, I got a blackscreen and could not do anything anymore (dmesg_drm2) so I had to poweroff the laptop by pressing the power button.
I'm currently typing this from the other attached boot.
I can use the X server normally but the monitor does not show anything despite xrandr telling that it is connected.
Comment 6 Joseph Thommes 2019-08-28 10:39:49 UTC
Created attachment 145185 [details]
dmesg_drm2
Comment 7 Joseph Thommes 2019-08-28 10:40:58 UTC
Created attachment 145186 [details]
dmesg_drm3
Comment 8 Joseph Thommes 2019-08-28 10:41:27 UTC
Created attachment 145187 [details]
i915_display_info
Comment 9 Joseph Thommes 2019-08-28 10:41:58 UTC
Created attachment 145188 [details]
xrandr_output
Comment 10 Lakshmi 2019-08-29 07:20:42 UTC
(In reply to Joseph Thommes from comment #8)
> Created attachment 145187 [details]
> i915_display_info

Is it connected through HDMI here? 
Are these results from drmtip? If not, can you please verify the issue with drmtip?
Comment 11 Joseph Thommes 2019-08-29 19:16:33 UTC
Yes the monitor is connected through the HDMI port of the dock and yes this was with the drmtip kernel.
Comment 12 Lakshmi 2019-08-30 10:16:36 UTC
(In reply to Joseph Thommes from comment #6)
> Created attachment 145185 [details]
> dmesg_drm2

(In reply to Joseph Thommes from comment #7)
> Created attachment 145186 [details]
> dmesg_drm3

Can you attach from boot(from 0 seconds)?
Comment 13 Lakshmi 2019-10-02 19:08:03 UTC
(In reply to Lakshmi from comment #12)
> (In reply to Joseph Thommes from comment #6)
> > Created attachment 145185 [details]
> > dmesg_drm2
> 
> (In reply to Joseph Thommes from comment #7)
> > Created attachment 145186 [details]
> > dmesg_drm3
> 
> Can you attach from boot(from 0 seconds)?

Can you please attach the full log?
Comment 14 Joseph Thommes 2019-10-07 19:41:36 UTC
Hi everyone,
I finally had time to recompile the kernel and perform the procedure again, but this time with sufficient memory for logging. So please find the new log attached. If there is anything more I can do, let me know.
Comment 15 Joseph Thommes 2019-10-07 19:43:11 UTC
Created attachment 145677 [details]
Complete log with monitor attached
Comment 16 Lakshmi 2019-10-10 08:40:15 UTC
(In reply to Joseph Thommes from comment #14)
> Hi everyone,
> I finally had time to recompile the kernel and perform the procedure again,
> but this time with sufficient memory for logging. So please find the new log
> attached. If there is anything more I can do, let me know.

Have you tried to connect the external monitor directly to the laptop (through HDMI). Was it working fine?

How do you recover from the situation?
Comment 17 Joseph Thommes 2019-10-10 08:57:15 UTC
Hi,
yes the monitors work just fine when connected to the laptop directly.
What exactly do you mean with recover?
In the case of the last log, I had to forcefully power off my laptop as it was completely stuck. If I pull the HDMI cable before, I can just continue working with the laptop, but if I wait long enough, it will get stuck.
Comment 18 Lakshmi 2019-10-10 11:55:06 UTC
(In reply to Joseph Thommes from comment #17)
> Hi,
> yes the monitors work just fine when connected to the laptop directly.
> What exactly do you mean with recover?
> In the case of the last log, I had to forcefully power off my laptop as it
> was completely stuck. If I pull the HDMI cable before, I can just continue
> working with the laptop, but if I wait long enough, it will get stuck.

Ok, thanks for the answer. 

Setting the priority and severity of the issue based on the impact.
Comment 19 Jani Saarinen 2019-10-10 13:55:41 UTC
Have you tried booting only console with same setup? So add these drm.debug=0xe log_buf_len=1M 3 and report if this helps.
Comment 20 Joseph Thommes 2019-10-10 14:25:37 UTC
Created attachment 145697 [details]
dmesg_drm_debug=0xe

I started the laptop in the dock with the monitor connected. I did dmesg -w | tee "file" in a tty. After the spamming of the kernel stopped, I logged into my X-Session and tried to change the solution of the monitor (which was shown as active and detected, but nothing arrived at it) to 3840x2160 in arandr (which is the maximum it can handle) and at this point my computer got completely stuck. Pulling the hdmi and even disconnecting the dock both did not work and I had to forcefully power off my PC.
Note that the monitor from this and the last time is not the same as in the beginning (actually this time it's a TV), but the same problem shows. Sadly I do not have access to the first monitor until christmas, if that would be necessary.
Comment 21 Joseph Thommes 2019-10-10 14:28:06 UTC
I don't know what exactly you mean with only console. Do you mean not starting a login manager/x-session? If you mean it like this, then yes, this is my standard setup. I need to login in tty1 to start a X session. If I do it in another tty, no X server is started.
Comment 22 Lakshmi 2019-10-10 14:33:41 UTC
(In reply to Joseph Thommes from comment #17)
> Hi,
> yes the monitors work just fine when connected to the laptop directly.
> What exactly do you mean with recover?
> In the case of the last log, I had to forcefully power off my laptop as it
> was completely stuck. If I pull the HDMI cable before, I can just continue
> working with the laptop, but if I wait long enough, it will get stuck.

@Stan, any help here?
Comment 23 Stanislav Lisovskiy 2019-10-10 15:30:59 UTC
Seems like one more MST issue, we had similar issues before and it is well known that some displays/docks behave in a weird way while in MST mode. Like setting weird dpcd values, sink count and whatever.

Need additional investigation, regarding what is wrong in this particular case, I think I have a similar display on my table now, so once I finish with that once, fix might help here as well(if it is curable at all).

As for computer hang, I guess this is related to that dmesg seems to be flooded with spurious hpd(hotplug) irqs and seems that irq storm detection didn't help here.

Currently the only thing to check is that whether does it behave same way on console mode(guess it does) and try to force the display to non-mst mode(in display menu there can be such option).


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.