Bug 109668

Created attachment 143400 [details]
libdrm debug output - #26+#27 are the error=-22 ones

Created attachment 143401 [details] [review]
libdrm debug patch (+errors suppression)

Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
eDP-1 connected (normal left inverted right x axis y axis)
   1920x1080     60.01 +  60.01    59.97    59.96    59.93    48.01  
...
DP-1-2 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160     60.00*+  30.00  
...

Using only the external 3840x2160 display, 1920x1080 is turned off in X (MATE).

In Xorg.0.log the crash (due to libdrm error) is shown as:

[125371.707] (EE) modeset(0): failed to set mode: No such file or directory
[125371.707] (EE)
Fatal server error:
[125371.707] (EE) EnterVT failed for screen 0
...
[125372.555] (EE) Server terminated with error (1). Closing log file.

Jan, correct if I misunderstood the issue.

switching to text console and back (using ctrl-alt-f2 and ctrl-alt-f1) crashes X server.
But, after applying the attached patch libdrm debug patch (+errors suppression), you noticed that X server didn't crash but display remains black.

(In reply to Lakshmi from comment #5)
> Jan, correct if I misunderstood the issue.
> 
> switching to text console and back (using ctrl-alt-f2 and ctrl-alt-f1)
> crashes X server.
> But, after applying the attached patch libdrm debug patch (+errors
> suppression), you noticed that X server didn't crash but display remains
> black.

Jan replied back saying "Yes, right." to the above question.

I have similar issues. I have seen the same log entry with modeset 0 when switching to vt.

Sometimes the screens doesnt come up after sleep.

And sometimes the computer goes slow and then almost freezes, down to the point the keyboard doesn't respond, but mouse reacts sometimes.

It is on two different older intel laptops. 

Most issues is with the one connected in a docking station, which was the one I saw this error for.

It isn't new, but it has been better or worse.

Brgds from Martin

(In reply to martin+foss from comment #7)
> Most issues is with the one connected in a docking station,

I have found the problem may be in the Thuderbold 3 Lenovo docking station itself.  As even after powercycling the laptop (X1 Carbon) it still did not work until I powercycled the docking station.

Maybe because I still have the original firmware 1.0 as I failed to upgrade it to 2.0 as it is Windows-only (and the firmware upgrade even failed in Windows I installed for it) - they have some new firmware upgrade tool now but it is again only for Windows:
https://support.lenovo.com/us/en/solutions/acc100356

I have the same problem on my T420 with Intel IGP. I noticed this only when I'm hooked on external monitor via displayport (I do not have docking station)

Created attachment 144426 [details] [review]
xorg-x11-server-1.20.4-1.fc29 patch

xorg-x11-server-1.20.4-1.fc29 patch although it is equivalent to what the libdrm patch 143401 does - ignore any errors from drmModeAtomicCommit().

I can confirm it is unrelated to docking station.  When I removed the docking station (connected to LG 27UK650 (Xorg.log id "LG HDR 4K") by DisplayPort) and connected the display directly to Lenovo X1 Carbon HDMI port it did behaved the same.

Besides ctrl-alt-Fx switching consoles the problem also happens after DPMS Off (xlock -dpmsoff), I have changed it now to DPMS Suspend (xlock -dpmssuspend) and it looks as the locked up display does not happen anymore.

With this patch screen remains black and one can recover it by disconnecting and reconnected the display (after resuming from DPMS Off); the same can be done by disconnecting+reconnecting the docking station (or powercycling the docking station).

I have also updated main BIOS of Lenovo X1 Carbon to 1.38 now, no effect (it even appears to me it happens more often than with 1.34 before).

Created attachment 144500 [details]
i915 successful resume after xlock -dpmoff 1

Created attachment 144501 [details]
i915 failed resume after alt-f1 back to the X

The problem is that "enabled/connectors mismatch" but where is the problem?
kernel-5.1.8-200.fc29.x86_64

-=working xlock resume
+=black/failing alt-f1
 i915 0000:00:02.0: [drm] crtc[47]: pipe A
 i915 0000:00:02.0: [drm]       enable=0
 i915 0000:00:02.0: [drm]       active=0
 i915 0000:00:02.0: [drm]       planes_changed=0
 i915 0000:00:02.0: [drm]       mode_changed=0
 i915 0000:00:02.0: [drm]       active_changed=0
 i915 0000:00:02.0: [drm]       connectors_changed=0
 i915 0000:00:02.0: [drm]       color_mgmt_changed=0
 i915 0000:00:02.0: [drm]       plane_mask=1
-i915 0000:00:02.0: [drm]       connector_mask=0
-i915 0000:00:02.0: [drm]       encoder_mask=4
+i915 0000:00:02.0: [drm]       connector_mask=1
+i915 0000:00:02.0: [drm]       encoder_mask=1
 i915 0000:00:02.0: [drm]       mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
-i915 0000:00:02.0: [drm] connector[86]: DP-5
-i915 0000:00:02.0: [drm]       crtc=(null)
 [drm:drm_atomic_check_only [drm]] checking 000000004664b9ab
 [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:47:pipe A] mode changed
 [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:47:pipe A] enable changed
 [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:47:pipe A] active changed
-[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:86:DP-5]
-[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling [CONNECTOR:86:DP-5]
+[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:47:pipe A] enabled/connectors mismatch

It has been fixed (workarounded?) by Driver "intel" from:
  https://bugzilla.redhat.com/show_bug.cgi?id=1630367#c18
There is also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1697591

It in effect does:
        -LoadModule: "fb"
        -LoadModule: "fbdevhw"
        -LoadModule: "glamoregl"
        -LoadModule: "modesetting"
        +LoadModule: "dri2"
        +LoadModule: "dri3"
        +LoadModule: "intel"
        +LoadModule: "present"

(In reply to Jan Kratochvil from comment #13)
> It has been fixed (workarounded?) by Driver "intel" from:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1630367#c18
> There is also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1697591
> 
> It in effect does:
>         -LoadModule: "fb"
>         -LoadModule: "fbdevhw"
>         -LoadModule: "glamoregl"
>         -LoadModule: "modesetting"
>         +LoadModule: "dri2"
>         +LoadModule: "dri3"
>         +LoadModule: "intel"
>         +LoadModule: "present"

Thanks for the feedback. Would you mind if I close this issue?

So it is not a bug in the userland Intel driver but isn't there some bug in the kernel i915 driver? Why is the 'connector' missing there in some cases?

Hi Kratochvil,

drm_atomic_helper_check_modeset() is used to validate state object for modeset changes. This function is returning EINVAL. In turn, IOCTL is getting failed. 

We entered into the above scenario because blob which is used for setting mode property for CRTC is NULL which leads to NOMODE and setting state->enable to false.
[drm:drm_atomic_set_mode_prop_for_crtc [drm]] Set [NOMODE] for [CRTC:47:pipe A] state 00000000b992248f

Which later leads to "enabled/connectors mismatch".

Looks like it may not be a driver issue and it could be how commits are being sent from the userland in case of switching from console to graphics mode.

Tried with vanilla Ubuntu 16.04 with 2 external displays and kernel version 5.1.0+ however was not able to reproduce issue.

If you are still getting the issue with the latest kernel, please send proper steps to reproduce the issue with proper configuration like which all displays getting used, kernel version, display_info, userland library details etc. 

#assessed

Reporter, can you check if issue still exists with latest drm-tip?

(In reply to Jani Saarinen from comment #17)
> Reporter, can you check if issue still exists with latest drm-tip?

You can read in Comment 0 that I am unable to boot drm-tip.

Let's close this Bug, I am sorry I am no longer going to spend time on this, I got too busy with too much unrelated stuff.

It works after forcing the Intel driver for X11:

cat >/etc/X11/xorg.conf.d/20-intel.conf <<EOH
# https://bugzilla.redhat.com/show_bug.cgi?id=1630367#c18
# https://bugzilla.redhat.com/show_bug.cgi?id=1697591
# https://bugzilla.redhat.com/show_bug.cgi?id=1662057
Section "Device"
	Identifier "Intel Graphics"
	Driver "intel"
EndSection
EOH