Bug 111502 - Dell XPS15 (HD530 & GeForce 950) external screen via dock/HDMI no text display & gdm freeze
Summary: Dell XPS15 (HD530 & GeForce 950) external screen via dock/HDMI no text displa...
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-27 12:54 UTC by HaJo Schatz
Modified: 2019-09-11 12:02 UTC (History)
3 users (show)

See Also:
i915 platform: SKL
i915 features: display/Other


Attachments
multiple logs (39.07 KB, application/gzip)
2019-08-27 12:54 UTC, HaJo Schatz
no flags Details
dmesg for failing kernel with drm debug enabled (289.42 KB, text/x-log)
2019-08-27 14:27 UTC, HaJo Schatz
no flags Details
drm-tip logs (40.96 KB, application/x-xz)
2019-08-30 11:50 UTC, HaJo Schatz
no flags Details
dmesg of kernel checked out 2019-09-11_10:04UTC (260.86 KB, text/plain)
2019-09-11 11:23 UTC, HaJo Schatz
no flags Details

Description HaJo Schatz 2019-08-27 12:54:18 UTC
Created attachment 145176 [details]
multiple logs

Fedora 30, Dell XPS15 9550 with Intel HD530, GeForce 950 cards, dual-screen setup with external display connected through Dell WD15 TB dock and HDMI

Setup worked until kernel 5.0. It broke somewhere around kernel 5.1:

- Booting to runlevel 3, external display remains off
- Booting to gdm, external display remains off during boot, system freezes on gdm start

Attached lspci, lsmod and dmesg for both (working) kernel 5.0 and (failing) kernel 5.2. FWIW also attached a failing Xorg.log of kernel 5.2.

Sorry for the tagging, I'm not even sure if this is a i915, nouveau or kernel issue.
Comment 1 Ilia Mirkin 2019-08-27 14:14:08 UTC
The ultimate issue is a modeset failure:

[   107.379] (EE) modeset(0): failed to set mode: No space left on device

Pretty sure that nouveau's not involved since there are, it seems, no connectors hanging off the NVIDIA device. Try booting one of the failing kernels with

drm.debug=0x1e

which should hopefully reveal more information about what's going wrong.
Comment 2 HaJo Schatz 2019-08-27 14:27:19 UTC
Created attachment 145177 [details]
dmesg for failing kernel with drm debug enabled
Comment 3 Lakshmi 2019-08-28 08:15:04 UTC
(In reply to HaJo Schatz from comment #2)
> Created attachment 145177 [details]
> dmesg for failing kernel with drm debug enabled

Can you verify if the issue is reproducible with drmtip (https://cgit.freedesktop.org/drm-tip)?
Comment 4 HaJo Schatz 2019-08-30 11:50:11 UTC
Created attachment 145217 [details]
drm-tip logs

Apologies, took a while to compile & run that. Result is the same failure, 2nd display is dead. Attached are dmesg logs both with and without drm.debug enabled of drm-tip cloned 2019-08-28, 18:30 UTC+8

Meanwhile I also noticed that the "defective" kernels/modules >5.0 configure something in the dock(?) which subsequently makes the "working" kernels very unstable. 
Seems like some register settings in the dock which do not get initialized by the working kernels <= 5.0, so those then crash, don't serve dock-connected HIDs, etc. Need to power-down the dock for an extended time (30mins+) to get back to a stable hardware after one of the 5.1+ kernels ran.
Comment 5 Lakshmi 2019-09-02 13:06:35 UTC
(In reply to HaJo Schatz from comment #4)
> Created attachment 145217 [details]
> drm-tip logs
> 

> Seems like some register settings in the dock which do not get initialized
> by the working kernels <= 5.0, so those then crash, don't serve
> dock-connected HIDs, etc. Need to power-down the dock for an extended time
> (30mins+) to get back to a stable hardware after one of the 5.1+ kernels ran.

Is it the same with drmtip? If you power-down the dock for the same time period as said above, external screen is working fine with drmtip kernel?
Comment 6 HaJo Schatz 2019-09-03 14:02:11 UTC
Lakshmi,

external screen _never_ works with drm-tip. 

After booting drm-tip kernel with dock attached, even the previously working 5.0 kernel easily freezes. Remedy is to poer off dock for some 30 mins. 

The 5.0 kernel however is always stable when dock is not connected. Hence I assume there's some mis-configuration going on in the dock for drm-tip.
Comment 7 Lakshmi 2019-09-06 11:51:49 UTC
(In reply to HaJo Schatz from comment #6)
> Lakshmi,
> 
> external screen _never_ works with drm-tip. 
> 
> After booting drm-tip kernel with dock attached, even the previously working
> 5.0 kernel easily freezes. Remedy is to poer off dock for some 30 mins. 
> 
> The 5.0 kernel however is always stable when dock is not connected. Hence I
> assume there's some mis-configuration going on in the dock for drm-tip.

Ok, thanks for gathering logs from drmtip. We will investigate the issue.
Comment 8 Imre Deak 2019-09-10 12:23:43 UTC
Could you check if your kernel has

commit bb1a71f9c4672fbfcf2158fd57d0c5c0cdae5612
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Aug 28 13:20:59 2019 +0300

    drm/i915: Limit MST to <= 8bpc once again

and if not retry with that patch applied?

In your case the MST modeset fails with >8bpc mode:
[    3.638886] [drm:drm_dp_mst_atomic_check [drm_kms_helper]] [MST PORT:00000000400f0099] requires 65 vcpi slots
[    3.638888] [drm:drm_dp_mst_atomic_check [drm_kms_helper]] [MST PORT:00000000400f0099] not enough VCPI slots in mst state 0000000007efd79c (avail=63)

...

[    3.639117] [drm:intel_plane_destroy [i915]] cpu_transcoder: B, pipe bpp: 36, dithering: 0

The failure shouldn't cause a machine hang, but it's worth trying if the failure path leads to it somehow. Your case is also only about 1 MST stream, unlike the case the above commit fixes, so looks like we also calculate the available bandwidth incorrectly.

Adding Ville for more ideas.
Comment 9 HaJo Schatz 2019-09-11 11:23:56 UTC
Created attachment 145331 [details]
dmesg of kernel checked out 2019-09-11_10:04UTC

Imre,

I missed that patch by a couple of hours. Just tried with current kernel as of today: The problem is gone. Current kernel boots, both to runlevel 3 supporting external devices at dock and into GDM/Wayland. Very happy, grateful user here.

Attached is the verbose dmesg of the sucessful RL3 boot in case you're looking for further improvement. Let me know if I can help with further testing, more than glad to do so!


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.