Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.

Also, what exact HW are you using?

You do not have the i915 kernel driver loaded. Without the dmesg from boot we cannot tell you why this might be, but most likely the module hasn't been compiled/installed.

Closing this now, please re-open if you still see the issue and attach the requested logs.

Created attachment 141054 [details]
dmesg as requests

Created attachment 141055 [details]
system log for non working modesetting after mod probing

Created attachment 141056 [details]
Waiting 5 minutes and restarting GDM

I wait a few minutes and try restarting GDM sometimes it works. You can see in t his log that the error isn't there:
ie. this was the error from the previous log,
Aug 13 02:35:36 as /usr/libexec/gdm-x-session[1222]: (EE) modeset(0): failed to set mode: Invalid argument
and it's gone

I attached 3 logs.

The first, dmesg is the output from modprobing the i915 driver 2.5 minutes after boot, after manually adding drm with debug options as requested.

The second is the output from the journal, which shows the error:

Aug 13 02:35:36 as /usr/libexec/gdm-x-session[1222]: (EE) modeset(0): failed to set mode: Invalid argument

The third is a successull start after retrying restarting GDM a few minutes after boot.

The hardware is an ASUS UX31A with BIOS version 219. I don't know what version of Intel GOP and video BIOS this has. And no this cannot be updated by some UEFI hacks.

The machine was working find until about 3 months ago.

Thanks again.

And these logs were with kernel version 4.17.14

Can you try testing latest https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e log_buf_len=4M?

Note that on our CI IVB systems are fine.

Moving to right component as Chris says:
"t's a bug in Xorg"

Vague recollection of it being a bug in the atomic modesetting rework since fixed.

(In reply to Chris Wilson from comment #12)
> Vague recollection of it being a bug in the atomic modesetting rework since
> fixed.

I have very strong recollections of this machine crashing a few years ago with i915 driver for months on end. I also remember that this chipset was mean to support IOMMU (ie. VT-d) and I haven't seen that ever work. I also remember the TSX debacle, which rendered haswell's and broadwells cripppled, and now we have the so called speed ups in recent generations of intel cruft being riddled with great gapping security holes. But I digressed.

I tried the same build in a VT-d enviromentment on other intel hardware, some crippled haswell IP and it worked a treat. I don't know if this is display is on a display port or whatever pipe is used to connect it to the smoke an mirrors.

I did find this in the xorg server changelog 
commit c256e31a9eba20da259f31ee70d1c8e1870993f1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 19 14:38:19 2018 +0200

    modesetting: Fix cirrus 24bpp breakage
    
    The recent rewrite of modesetting driver broke the 24bpp support.
    As typically found on cirrus KMS, it leads to a blank screen, spewing
    the error like:
      failed to add fb -22
      (EE) modeset(0): failed to set mode: Invalid argument
    
    The culript is that the wrong bpp value of the front buffer is passed
    to drmModeAddFB().  Fix it by replacing with the back buffer bpp,
    drmmode->kbpp.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Stefan Dirsch <sndirsch@suse.de>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    (cherry picked from commit d625e16918ef9104863709eb108346464767c444)


I don't know if it is related.

Whatever, I just tried this patch and I get 100% X startup success:


de_display.c.orig  ./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c
--- ./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c.orig	2018-08-07 16:31:03.000000000 +0000
+++ ./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c	2018-08-18 23:34:43.820435159 +0000
@@ -1494,10 +1494,8 @@
         if (drmmode_crtc_set_mode(crtc, can_test)) {
             xf86DrvMsg(crtc->scrn->scrnIndex, X_ERROR,
                        "failed to set mode: %s\n", strerror(errno));
-            ret = FALSE;
-            goto done;
-        } else
-            ret = TRUE;
+	}
+        ret = TRUE;
 
         if (crtc->scrn->pScreen)
             xf86CrtcSetScreenSubpixelOrder(crtc->scrn->pScreen);

PS: The MAC addresses in the log files are fake

Thanks again Chipzilla.

Please try current i915 and modesetting drivers.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/56.