Bug 108460 - screen behind docking station doesn't work properly during boot
Summary: screen behind docking station doesn't work properly during boot
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Stanislav Lisovskiy
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-10-16 19:35 UTC by Johannes Berg
Modified: 2019-02-07 08:56 UTC (History)
3 users (show)

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


Attachments
display not turned on by kernel on boot (4.35 MB, image/jpeg)
2018-10-16 19:35 UTC, Johannes Berg
no flags Details
display turned on by gdm (4.64 MB, image/jpeg)
2018-10-16 19:35 UTC, Johannes Berg
no flags Details
dmesg log (captured via journalctl as 1M log buffer wasn't enough) (7.74 MB, text/plain)
2018-10-16 19:37 UTC, Johannes Berg
no flags Details
vbios dump (64.00 KB, application/octet-stream)
2018-10-16 19:38 UTC, Johannes Berg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Berg 2018-10-16 19:35:32 UTC
Created attachment 142048 [details]
display not turned on by kernel on boot

DRM tip tree, commit 90b59df999a1 ("drm-tip: 2018y-10m-15d-20h-57m-27s UTC integration manifest")

Fedora 28 system on an HP EliteBook Folio G1 with Intel(R) Core(TM) m7-6Y75 CPU, x86_64 of course.

I have two external monitors connected:
 * one directly by USB-C display port cable
 * one via docking station (https://www.iogear.com/product/GUD3C01/), connected with HDMI

During boot, where you enter the disk password, and the Fedora logo is displayed, the second one stays blank. It does come out of powersave, but stays blank rather than showing the Fedora logo and password entry etc. It comes on properly when GDM starts up. See the two attached images - one with the fedora boot logo, the other with the GDM screen (the actual input screen is on the laptop display, so not visible).

This is a regression, but I cannot exactly say when it was introduced. I know it works on 4.13 (I installed this due to the other bug I'm about to file), and I believe it still worked on 4.15, but I don't have that installed now to test.
Comment 1 Johannes Berg 2018-10-16 19:35:59 UTC
Created attachment 142049 [details]
display turned on by gdm
Comment 2 Johannes Berg 2018-10-16 19:37:11 UTC
Created attachment 142051 [details]
dmesg log (captured via journalctl as 1M log buffer wasn't enough)
Comment 3 Johannes Berg 2018-10-16 19:38:40 UTC
Created attachment 142052 [details]
vbios dump
Comment 4 Stanislav Lisovskiy 2018-10-17 13:34:48 UTC
Would be nice to attach also Xserver and gdm logs to see if they got correspondent uevents and got connector states updated properly. 
There are no such problems with Ubuntu 16/18 at least with the same kernel. I've seen a similar bug and the problem was that gdm sometimes simply didn't initiate modeset for some connectors.

From the logs I see here:

cat bug-108460.log | grep -iE "(status updated)|(mode_setcrtc)|(session opened for user)"
Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:83:eDP-1] status updated from unknown to connected
Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:91:DP-1] status updated from unknown to disconnected
Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:102:DP-2] status updated from unknown to connected
Oct 16 23:24:54 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:149:DP-3] status updated from unknown to connected
Oct 16 23:24:54 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:109:DP-4] status updated from unknown to disconnected
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B]
Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2]
Oct 16 21:25:26 jberg1-mobl2.ger.corp.intel.com systemd[1520]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Oct 16 21:25:26 jberg1-mobl2.ger.corp.intel.com gdm-launch-environment][1456]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Oct 16 21:25:30 jberg1-mobl2.ger.corp.intel.com systemd[1831]: pam_unix(systemd-user:session): session opened for user jberg1 by (uid=0)
Oct 16 21:25:30 jberg1-mobl2.ger.corp.intel.com sshd[1716]: pam_unix(sshd:session): session opened for user jberg1 by (uid=0)
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A]
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1]
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B]
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2]
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:81:pipe C]
Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:149:DP-3]

As you can see the kernel updates status to connected for eDP-1, DP-2, DP-3, but we get drm_mode_setcrtc only for eDP-1, DP-2 before you login. Then we finally get 
drm_mode_setcrtc for all of the connectors, after login. drm_mode_setcrtc is initiated by DRM_IOCTL_MODE_SETCRTC ioctl which sent from XServer after gdm requests it.Kernel doesn't initiate it by itself. Also I bet xrandr would show that all connectors are in connected state - then this is most likely more a gdm/XServer issue, rather than kernel.
Comment 5 Johannes Berg 2018-10-17 13:37:46 UTC
(In reply to Stanislav Lisovskiy from comment #4)
> Would be nice to attach also Xserver and gdm logs to see if they got
> correspondent uevents and got connector states updated properly. 
> There are no such problems with Ubuntu 16/18 at least with the same kernel.
> I've seen a similar bug and the problem was that gdm sometimes simply didn't
> initiate modeset for some connectors.

Wait, I'm talking about boot, I don't think Xserver/gdm are relevant?

This is what happens directly after grub, basically. You don't have anything but initramfs, I'd be very surprised if Fedora was putting Xserver and/or gdm there.

Though perhaps I could check what happens if I make the boot non-quiet, and let boot messages scroll through - I suspect they will only show up on one external screen too.
Comment 6 Stanislav Lisovskiy 2018-10-17 14:08:12 UTC
(In reply to Johannes Berg from comment #5)
> (In reply to Stanislav Lisovskiy from comment #4)
> > Would be nice to attach also Xserver and gdm logs to see if they got
> > correspondent uevents and got connector states updated properly. 
> > There are no such problems with Ubuntu 16/18 at least with the same kernel.
> > I've seen a similar bug and the problem was that gdm sometimes simply didn't
> > initiate modeset for some connectors.
> 
> Wait, I'm talking about boot, I don't think Xserver/gdm are relevant?
> 
> This is what happens directly after grub, basically. You don't have anything
> but initramfs, I'd be very surprised if Fedora was putting Xserver and/or
> gdm there.
> 
> Though perhaps I could check what happens if I make the boot non-quiet, and
> let boot messages scroll through - I suspect they will only show up on one
> external screen too.

You are right, this is actually a bit different. I will check on how it should behave in that case.
Comment 7 Johannes Berg 2018-10-17 19:13:00 UTC
(In reply to Stanislav Lisovskiy from comment #6)

> You are right, this is actually a bit different. I will check on how it
> should behave in that case.

Fair enough, I guess, it used to display on all screens. I can't really say it bothers me tremendously, even if I typically use the one that goes blank as my "main" screen I can certainly enter the boot password anyway :-)
Comment 8 Johannes Berg 2018-10-18 09:40:26 UTC
(In reply to Johannes Berg from comment #7)
> (In reply to Stanislav Lisovskiy from comment #6)
> 
> > You are right, this is actually a bit different. I will check on how it
> > should behave in that case.
> 
> Fair enough, I guess, it used to display on all screens. I can't really say
> it bothers me tremendously, even if I typically use the one that goes blank
> as my "main" screen I can certainly enter the boot password anyway :-)

FWIW, as of 4.17-rc5 (commit 10cfc747835e34c) which I'm randomly running now while trying to bisect bug 108462, it still turns on both screens during boot.
Comment 9 Johannes Berg 2018-10-18 10:43:21 UTC
Ok, hmmm. This depends on the kernel .config, now with the current config ("make localmodconfig") on the same DRM tip tree (commit 90b59df999a1) it works fine ...

One (perhaps significant) difference that I notice it that this kernel now shows the 4 boot-time penguins, which is not the case on Fedora's config.

Any thoughts as to what Kconfig knobs might affect this that I can play with?

Then perhaps with that I can even bisect the issue, but first I have to find a non-fedora config (it takes too long to compile...) that actually has it!
Comment 10 Johannes Berg 2018-10-27 21:06:36 UTC
So I've found a kernel .config where the external screens *both* aren't even turned on, I've attached both a good (except for sound) config, and a bad (no external screens at all) config to bug 108462, the diff between them is simple:


+CONFIG_REGMAP_I2C=m
+CONFIG_SND_HDA_EXT_CORE=m
+CONFIG_SND_SOC=m
+CONFIG_SND_SOC_TOPOLOGY=y
+CONFIG_SND_SOC_ACPI=m
+CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
+CONFIG_SND_SOC_INTEL_SST=m
+CONFIG_SND_SOC_INTEL_SKYLAKE=m
+CONFIG_SND_SOC_ACPI_INTEL_MATCH=m
+CONFIG_SND_SOC_INTEL_MACH=y
+CONFIG_SND_SOC_I2C_AND_SPI=m
Comment 11 Lakshmi 2018-12-18 05:52:44 UTC
Stan, any comments here?
Comment 12 Johannes Berg 2019-01-05 07:36:10 UTC
So, I'm unable to figure out what's going on, but with the new kernel I installed recently (4.19.13) this issue appears to be fixed. Of course I don't know if Fedora just changed the default config or if there really were any code changes ... (remember that I never was able to figure out the particular Kconfig setting that _broke_ it to start with)
Comment 13 Lakshmi 2019-02-07 08:56:25 UTC
(In reply to Johannes Berg from comment #12)
> So, I'm unable to figure out what's going on, but with the new kernel I
> installed recently (4.19.13) this issue appears to be fixed. Of course I
> don't know if Fedora just changed the default config or if there really were
> any code changes ... (remember that I never was able to figure out the
> particular Kconfig setting that _broke_ it to start with)

Thanks for the feedback. We always recommend to update kernel to latest, that did the trick. Closing this bug.


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.