Bug 104425 - [KBL] Dell TB16 external displays blank in kernel 4.14.4+
Summary: [KBL] Dell TB16 external displays blank in kernel 4.14.4+
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: highest critical
Assignee: Jose Roberto de Souza
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2017-12-31 21:33 UTC by Ian Pilcher
Modified: 2018-04-26 07:11 UTC (History)
8 users (show)

See Also:
i915 platform: KBL
i915 features: display/DP MST


Attachments
dmesg from working kernel (commit 56350fb8978bbf4aafe08f21234e161dd128b417) (229.02 KB, text/plain)
2017-12-31 21:33 UTC, Ian Pilcher
no flags Details
dmesg from non-working kernel (commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643) (133.99 KB, text/plain)
2017-12-31 21:34 UTC, Ian Pilcher
no flags Details
WIP patch fix (1.53 KB, patch)
2018-04-17 21:30 UTC, Jose Roberto de Souza
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Pilcher 2017-12-31 21:33:30 UTC
Created attachment 136464 [details]
dmesg from working kernel (commit 56350fb8978bbf4aafe08f21234e161dd128b417)

TL;DR - Commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 breaks external displays attached to a Dell TB16 dock.

Hardware is a Dell Precision 5520 "developer edition" laptop attached to a Dell TB16 (Thunderbolt 3) dock.  This laptop does not have a separate discrete GPU, only the GPU integrated into its Core i5 processor.

OS is Fedora 27, but dmesg files in this bug are from mainline kernel.

When the laptop is docked, it is closed, and I use *only* the displays (and keyboard, etc.) attached to the TB16.  This works fine up through commit 56350fb8978bbf4aafe08f21234e161dd128b417, but commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 causes the displays to be disabled as soon as the i915 module is loaded, leaving no working display at all.

I had a heck of a time preventing the i915 module from being loaded, so the two dmesg files were produced with the following sequence:

* Blacklist the i915 module in /etc/modprobe.d and rebuild the initramfs
* Rename the i915.ko file under /lib/modules/...
* Reboot to multi-user.target
* Remove the drm modules that somehow got auto-loaded
  - modprobe -r drm_kms_helper
  - modprobe -r drm
* Rename i915.ko back to its correct file name
* Load the drm and i915 modules with debugging enabled
  - modprobe drm debug=0x0f
  - modprobe i915
Comment 1 Ian Pilcher 2017-12-31 21:34:12 UTC
Created attachment 136465 [details]
dmesg from non-working kernel (commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643)
Comment 2 Ian Pilcher 2017-12-31 22:20:45 UTC
This also went into linux-stable (as 7042c2b9a19e74972f5783ab3b7ef98ebdee293f).
Comment 3 Ian Pilcher 2018-01-01 01:13:57 UTC
After a bit more debugging around I have determined that this patch does not *completely* disable the TB16-attached displays.  Instead, I ran into a combination of a couple of separate behaviors:

1.  If I allow the i915 module to be loaded by dracut, the displays *are* 
    disabled when the system is asking for my LUKS password.  Additionally, I
    have been unsuccessful in a pretty large number of attempts to blind-type
    the LUKS password, so it appears that something else is blocked as well
    (even though the NumLock LED on my keyboard does respond).

2.  systemd-logind was suspending my laptop, because the lid was closed and it
    did not detect any external displays.  Once I realized what was going on,
    I was able to work around this by setting HandleLidSwitch=ignore in
    logind.conf, but this is not a long-term solution.

If I boot with rd.driver.blacklist=i915 (so that I can enter my LUKS password before the i915 module is loaded) and prevent systemd-logind from suspending the system, then I am able to boot, and the TB16-attached displays are eventually enabled.
Comment 4 Ian Pilcher 2018-01-02 18:39:38 UTC
One other data point ... I discovered that the problem does not occur if I remove i915.panel_ignore_lid=0 from my kernel command line.  Of course, this does leave me with a non-functional display configuration.
Comment 5 Jani Nikula 2018-01-22 12:28:31 UTC
The regressing commit is

commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Nov 25 19:41:55 2017 +0000

    drm/i915/fbdev: Serialise early hotplug events with async fbdev config

Chris, any ideas?
Comment 6 Jose Roberto de Souza 2018-01-23 18:46:59 UTC
Looks like it is the same issue as https://bugs.freedesktop.org/show_bug.cgi?id=104158, for now you can disable MST to get it working: https://bugs.freedesktop.org/show_bug.cgi?id=104158#c37
Comment 7 Ian Pilcher 2018-01-24 13:28:12 UTC
(In reply to Jose Roberto de Souza from comment #6)
> Looks like it is the same issue as
> https://bugs.freedesktop.org/show_bug.cgi?id=104158, for now you can disable
> MST to get it working:
> https://bugs.freedesktop.org/show_bug.cgi?id=104158#c37

I can confirm that i915.enable_dp_mst=0 works around the issue on my system.

*** This bug has been marked as a duplicate of bug 104158 ***
Comment 8 Ian Pilcher 2018-02-16 17:43:43 UTC
Reopening, per https://bugs.freedesktop.org/show_bug.cgi?id=104158#c42

Issue still exists with kernel 4.15.2 on my (non-CFL) i5-7440HQ.
Comment 9 Jani Saarinen 2018-03-29 07:11:56 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 10 Ian Pilcher 2018-04-12 18:38:00 UTC
On 04/12/2018 04:29 AM, russianneuromancer@ya.ru wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=104425
> 
> Hi!
> 
> I wonder if this issue is still reproducible for you on current drm-tip?
> 

Just reproduced with today's drm-tip.
Comment 11 Jani Nikula 2018-04-17 14:52:13 UTC
Are you booting in UEFI or legacy BIOS mode?

What kernel command line parameters do you have? The dmesg doesn't include that part.
Comment 12 Ian Pilcher 2018-04-17 14:56:55 UTC
(In reply to Jani Nikula from comment #11)
> Are you booting in UEFI or legacy BIOS mode?

Legacy mode.

> What kernel command line parameters do you have? The dmesg doesn't include
> that part.

???

I see it on the 2nd line of the dmesg:

[    0.000000] Command line: ro root=/dev/mapper/luks-aae48458-c9e4-4291-b55c-bfb4675453df rd.md=0 rd.dm=0 rd.lvm.lv=vg_root/lv_root_f26 rd.luks.uuid=luks-aae48458-c9e4-4291-b55c-bfb4675453df elevator=deadline pci=noaer i915.panel_ignore_lid=0 LANG=en_US.UTF-8 quiet rhgb
Comment 13 Jani Nikula 2018-04-17 15:16:20 UTC
(In reply to Ian Pilcher from comment #12)
> (In reply to Jani Nikula from comment #11)
> > Are you booting in UEFI or legacy BIOS mode?
> 
> Legacy mode.

Please try UEFI boot and i915.panel_ignore_lid=0 removed.
Comment 14 Ian Pilcher 2018-04-17 15:57:14 UTC
(In reply to Jani Nikula from comment #13)
> Please try UEFI boot and i915.panel_ignore_lid=0 removed.

I've already tried removing i915.panel_ignore_lid=0.  (See comment #4.)

As to trying UEFI, this is my work laptop, so it will be a while before I have time to reconfigure it and install a new operating system.
Comment 15 Paul Menzel 2018-04-17 16:02:38 UTC
(In reply to Jani Nikula from comment #13)
> (In reply to Ian Pilcher from comment #12)
> > (In reply to Jani Nikula from comment #11)
> > > Are you booting in UEFI or legacy BIOS mode?
> > 
> > Legacy mode.
> 
> Please try UEFI boot and i915.panel_ignore_lid=0 removed.

Could you please document your theory, why this should make a difference?
Comment 16 frederik 2018-04-17 16:17:20 UTC
Can confirm that a45b30a6c5db631e2ba680304bd5edd0cd1f9643 causes a black screen while booting a Precision with attached TB16 (only external monitors, lid closed) using EFI. 

Bootflags: rw rootflags=subvol=orig/root  quiet

Adding i915.enable_dp_mst=0 works as a workaround but makes multi monitor setup useless.
Comment 17 Ian Pilcher 2018-04-17 18:21:06 UTC
Clearing NEEDINFO, as requested information has been provided.
Comment 18 Jose Roberto de Souza 2018-04-17 21:30:22 UTC
Created attachment 138886 [details] [review]
WIP patch fix

Could you fetch the drm-tip tree, apply this patch and test?
Comment 19 frederik 2018-04-17 22:20:33 UTC
Did not have the time for drm-tip but I tried the patch on top of 4.15.17 and it works. No black screens anymore and MST works too.

Thanks!
Comment 20 Jose Roberto de Souza 2018-04-17 22:26:46 UTC
Nice :D
thanks rederik
Comment 21 Jani Nikula 2018-04-18 05:18:12 UTC
(In reply to Ian Pilcher from comment #14)
> (In reply to Jani Nikula from comment #13)
> > Please try UEFI boot and i915.panel_ignore_lid=0 removed.
> 
> I've already tried removing i915.panel_ignore_lid=0.  (See comment #4.)

I meant UEFI with the parameter removed. Not either or.

(In reply to Paul Menzel from comment #15)
> Could you please document your theory, why this should make a difference?

Basically all new laptops have shipped with UEFI boot for years. The OEMs don't appear to test the legacy BIOS boot at all. We've had numerous issues with legacy boot, and basically we can't support that for new laptops. All bets are off. Typically, the VBT is different for the two, and often bogus for legacy boot, and more. Some really mysterious issues have just gone away by switching to UEFI.
Comment 22 Jose Roberto de Souza 2018-04-19 20:08:13 UTC
There is a simpler solution could you test this? https://patchwork.freedesktop.org/patch/217789/
Comment 23 frederik 2018-04-19 20:47:48 UTC
Works on top of 4.15.17. Any chance to get this into 4.16?
Thanks
frederik
Comment 24 Ian Pilcher 2018-04-19 21:20:58 UTC
(In reply to Jose Roberto de Souza from comment #22)
> There is a simpler solution could you test this?
> https://patchwork.freedesktop.org/patch/217789/

Also works on top of drm-tip (from 2018-04-12) with my configuration:

* legacy boot
* i915.panel_ignore_lid=0

(No more need for i915.enable_dp_mst=0.)
Comment 25 Jani Nikula 2018-04-24 14:18:06 UTC
Thanks for the report and testing, fixed by

commit df9e6521749ab33cde306e8a4350b0ac7889220a
Author: José Roberto de Souza <jose.souza@intel.com>
Date:   Wed Apr 18 16:41:58 2018 -0700

    drm/i915/fbdev: Enable late fbdev initial configuration

in drm-tip.


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.