| Summary: | Dell XPS15 (HD530 & GeForce 950) external screen via dock/HDMI no text display & gdm freeze | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | HaJo Schatz <hajo> | ||||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
| Severity: | major | ||||||||||||
| Priority: | high | CC: | imre.deak, intel-gfx-bugs, ville.syrjala | ||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||
| OS: | Linux (All) | ||||||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||||||
| i915 platform: | SKL | i915 features: | display/Other | ||||||||||
| Attachments: |
|
||||||||||||
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. Created attachment 145177 [details]
dmesg for failing kernel with drm debug enabled
(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)? 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.
(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? 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. (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. 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. 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.
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.