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
Created attachment 136465 [details] dmesg from non-working kernel (commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643)
This also went into linux-stable (as 7042c2b9a19e74972f5783ab3b7ef98ebdee293f).
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.
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.
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?
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
(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 ***
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.
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.
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.
Are you booting in UEFI or legacy BIOS mode? What kernel command line parameters do you have? The dmesg doesn't include that part.
(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
(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.
(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.
(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?
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.
Clearing NEEDINFO, as requested information has been provided.
Created attachment 138886 [details] [review] WIP patch fix Could you fetch the drm-tip tree, apply this patch and test?
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!
Nice :D thanks rederik
(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.
There is a simpler solution could you test this? https://patchwork.freedesktop.org/patch/217789/
Works on top of 4.15.17. Any chance to get this into 4.16? Thanks frederik
(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.)
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.