Bug 108460

Created attachment 142049 [details]
display turned on by gdm

Created attachment 142051 [details]
dmesg log (captured via journalctl as 1M log buffer wasn't enough)

Created attachment 142052 [details]
vbios dump

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.

(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.

(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.

(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 :-)

(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.

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!

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

Stan, any comments here?

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)

(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.