Looks like this is a regression of xorg-x11-drv-intel-2.99.917-26.20160929.el7.x86_64.

Test against rhel7.3 guest with kernel 3.10.0-646.el7.rhel74drm22.x86_64 and xorg-x11-drv-intel-2.99.917-22.20151206.el7.x86_64.

Use same xorg.conf:
# cat /etc/X11/xorg.conf.d/intel.conf
Section "Device"
   Identifier  "intel"
   Driver      "intel"
   BusID       "PCI:0:5:0"
EndSection 

Xorg can start successfully with a virtual monitor attached:
[   279.511] (==) AIGLX enabled
[   279.511] (II) LoadModule: "intel"
[   279.511] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[   279.511] (II) Module intel: vendor="X.Org Foundation"
[   279.511] 	compiled for 1.17.2, module version = 2.99.917
[   279.511] 	Module class: X.Org Video Driver
[   279.511] 	ABI class: X.Org Video Driver, version 19.0
[   279.511] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
	i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
	915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
	Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
	GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[   279.511] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[   279.511] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[   279.511] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300
[   279.511] (++) using VT number 1

[   279.512] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20161121
[   279.512] (--) intel(0): gen9 engineering sample
[   279.512] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 1 threads
[   279.512] (II) intel(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[   279.512] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[   279.513] (==) intel(0): RGB weight 888
[   279.513] (==) intel(0): Default visual is TrueColor
[   279.514] (II) intel(0): Output DP1 has no monitor section
[   279.514] (II) intel(0): Enabled output DP1
[   279.514] (II) intel(0): Output HDMI1 has no monitor section
[   279.514] (II) intel(0): Enabled output HDMI1
[   279.514] (II) intel(0): Output DP2 has no monitor section
[   279.514] (II) intel(0): Enabled output DP2
[   279.514] (II) intel(0): Output HDMI2 has no monitor section
[   279.514] (II) intel(0): Enabled output HDMI2
[   279.514] (II) intel(0): Output DP3 has no monitor section
[   279.514] (II) intel(0): Enabled output DP3
[   279.515] (II) intel(0): Output HDMI3 has no monitor section
[   279.515] (II) intel(0): Enabled output HDMI3
[   279.515] (--) intel(0): Using a maximum size of 256x256 for hardware cursors
[   279.515] (II) intel(0): Output VIRTUAL1 has no monitor section
[   279.515] (II) intel(0): Enabled output VIRTUAL1
[   279.515] (--) intel(0): Output DP3 using initial mode 1920x1200 on pipe 0
[   279.515] (==) intel(0): TearFree disabled
[   279.515] (==) intel(0): DPI set to (96, 96)
[   279.515] (II) Loading sub module "dri2"
[   279.515] (II) LoadModule: "dri2"
[   279.515] (II) Module "dri2" already built-in
[   279.515] (II) Loading sub module "present"
[   279.515] (II) LoadModule: "present"
[   279.515] (II) Module "present" already built-in
[   279.515] (==) Depth 24 pixmap format is 32 bpp
[   279.515] (II) intel(0): SNA initialized with generic backend
[   279.515] (==) intel(0): Backing store enabled
[   279.515] (==) intel(0): Silken mouse enabled
[   279.515] (II) intel(0): HW Cursor enabled
[   279.515] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   279.515] (==) intel(0): DPMS enabled
[   279.515] (==) intel(0): Display hotplug detection enabled
[   279.515] (II) intel(0): Textured video not supported on this hardware or backend
[   279.515] (II) intel(0): [DRI2] Setup complete
[   279.515] (II) intel(0): [DRI2]   DRI driver: i965
[   279.515] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[   279.515] (II) intel(0): direct rendering: DRI2 enabled
[   279.515] (II) intel(0): hardware support for Present enabled
[   279.515] (--) RandR disabled
[   279.518] (II) SELinux: Disabled by boolean
[   279.524] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   279.524] (II) AIGLX: enabled GLX_ARB_create_context
[   279.524] (II) AIGLX: enabled GLX_ARB_create_context_profile
[   279.524] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile
[   279.525] (II) AIGLX: enabled GLX_INTEL_swap_event
[   279.525] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[   279.525] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[   279.525] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[   279.525] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[   279.525] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[   279.525] (II) AIGLX: Loaded and initialized i965
[   279.525] (II) GLX: Initialized DRI2 GL provider for screen 0
[   279.545] (II) intel(0): switch to mode 1920x1200 on DP3 using pipe 0, position (0, 0), rotation normal, reflection none
[   279.562] (II) intel(0): Setting screen physical size to 508 x 317

Hi Gerd,

   Could you help to look at comment 2 and whether we should assign this issue to Paul?

BR/
Guo, Zhiyi

>    Could you help to look at comment 2 and whether we should assign this
> issue to Paul?

Yes, I think Paul should look at it.

qemu-kvm component most likely isn't correct though, should probably be either kernel or the xorg intel driver.  Paul can probably tell ...

Hi guys, I did the investigation with Zhiyi yesterday. We proved that this is not an issue of vGPU.

We directly put the disk of the "bad" machine(running RHEL 7.4, failing to start X on native) into the "good" machine (running RHEL 7.3) and start X on native. The "good" machine with RHEL 7.4 also shows the same problem (xorg-intel-driver cannot load).

Both of tests are performed under native. So it should be a problem of xorg-intel-driver not vGPU related.

Where does the source code of xorg-intel-driver in RHEL7.4 come from? Is it an offical release version or based on an existing version with backporting?

Thanks,
Zhi.

BTW: RHEL 7.3 (good machine) / RHEL 7.4 (bad machine) are using the same kernel.

Zhiyi can confirm that.

Thanks,
Zhi.

Hi,

So this bug seems to be in xorg-x11-drv-intel, re-assigning. I believe it never was the intention for the Fedora change to not use xorg-x11-drv-intel on skylake to ever make it into RHEL (as shown RHEL-7.3 does not do this).

If the graphics team does want to change the default driver for skylake+ gfx for 7.4, it should probably use the xserver patch from Fedora-26 for that and not the xorg-x11-drv-intel patch, then the user can at least still override the default such as is needed for the gvt-g gpu testing.

Regards,

Hans

The default driver for skylake 2D gfx driver for 7.4 use mode setting or Intel 2D gfx driver is not important, rhel7.4 should support both mode setting and Intel 2D gfx driver, or it will make some confuse for end user that why Intel 2D gfx driver support Broadwell but not support Skylake.
At least the newest xorg-intel-driver is a regression and we must fix it before release.

Looks like this never got fixed before release, as X fails to start on this machine:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)

Is there a workaround?

Nevermind - my issue appears to be due to having previously forced the intel driver and uxa acceleration.  Removing this allowed X to start.

I am also seeing that this was not fixed before release. 
Installing on a machine with HD520 graphics loads the vesa driver for graphical.target. 

Running

Xorg :2 -configure

and copying the new xorg.conf to /etc/X11/xorg.conf causes the boot to fail with 
[    ] (EE) No devices detected.
[    ] (EE)
Fatal server error:
[    ] (EE) no screens found(EE)

Installed both as legacy and UEFI.
When installing in RHEL7.3 intel driver is able to load and correctly renders. 

7.4 Intel Xorg Module: 2.99.917-26.20160929
7.3 Intel Xorg Module: 2.99.917-22.20151206

Only 'workaround' to get to GUI is to remove xorg.conf and let X use the vesa driver.

Same here - running CentOS 7.4 on Latitude 7470, and with latest/rebased xorg packages there's no way to get X started, so just reverting to this xorg-X11 packages set: 

xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.el7.x86_64
xorg-x11-drv-dummy-0.3.6-21.el7.x86_64
xorg-x11-drv-evdev-2.9.2-2.el7.x86_64
xorg-x11-drv-fbdev-0.4.3-20.el7.x86_64
xorg-x11-drv-intel-2.99.917-22.20151206.el7.x86_64
xorg-x11-drv-nouveau-1:1.0.11-4.el7.x86_64
xorg-x11-drv-qxl-0.1.1-18.el7.x86_64
xorg-x11-drv-synaptics-1.8.2-1.el7.x86_64
xorg-x11-drv-v4l-0.2.0-42.el7.x86_64
xorg-x11-drv-vesa-2.3.2-20.el7.x86_64
xorg-x11-drv-vmmouse-13.0.0-12.el7.x86_64
xorg-x11-drv-vmware-13.0.2-7.20150211git8f0cf7c.el7.x86_64
xorg-x11-drv-void-1.4.1-1.el7.x86_64
xorg-x11-drv-wacom-0.29.0-1.el7.x86_64
xorg-x11-server-Xorg-1.17.2-22.el7.x86_64
xorg-x11-server-common-1.17.2-22.el7.x86_64

fixes X. Conversely, I never had /etc/X11/xorg.conf, so either generating one or not doesn't help with the latest xorg-x11 packages. However, rolling back doesn't fix things completely: 2D rendering seems slow (2560x1440 image/graph takes about 2/10s to render.


Thanks,
Milos.

Rolling back the versions of xorg-x11 packages as in comment 12 did not work for me.  X started, very briefly, and then segfaulted:

[   151.666] (EE) Backtrace:
[   151.666] (EE) 0: /usr/bin/X (xorg_backtrace+0x55) [0x5607a8d6a995]
[   151.666] (EE) 1: /usr/bin/X (0x5607a8bb8000+0x1b6ca9) [0x5607a8d6eca9]
[   151.666] (EE) 2: /lib64/libc.so.6 (0x7fa01bddb000+0x35270) [0x7fa01be10270]
[   151.666] (EE) 3: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fa0170e0000+0x60c70) [0x7fa017140c70]
[   151.666] (EE) 4: /usr/bin/X (0x5607a8bb8000+0x1af670) [0x5607a8d67670]
[   151.667] (EE) 5: /usr/bin/X (WaitForSomething+0x6c2) [0x5607a8d67df2]
[   151.667] (EE) 6: /usr/bin/X (0x5607a8bb8000+0x581b1) [0x5607a8c101b1]
[   151.667] (EE) 7: /usr/bin/X (0x5607a8bb8000+0x5c37b) [0x5607a8c1437b]
[   151.667] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fa01bdfcc05]
[   151.667] (EE) 9: /usr/bin/X (0x5607a8bb8000+0x467be) [0x5607a8bfe7be]
[   151.667] (EE)
[   151.667] (EE) Segmentation fault at address 0x0
[   151.667] (EE)
Fatal server error:
[   151.667] (EE) Caught signal 11 (Segmentation fault). Server aborting

I have a complicated xorg.conf (zaphodheads) but the same config worked fine in 7.3

as of now my config is mostly unusable in 7.4

As of Xorg Server 1.19.3, the modesetting driver now works well with Kaby Lake hardware I have tested with. It's definitely better than vesa.

However, as Terrence Xu (comment 8) pointed out: modesetting isn't a complete replacement for the intel driver. 2D performance, virtualisation, colour management and other vendor-specific features aren't supported with xorg-x11-drv-modesetting.

Is the situation that bad with the Intel DDX, that support needs to be dropped before 7.6?

As opposed to some users' experience, for me neither rolling back to kernel 3.10.0-514.26.2.el7.x86_64, nor using vesa driver works with the latest xorg-X11 packages.

Could this issue be related to: 

https://bugzilla.redhat.com/show_bug.cgi?id=1342748


?

is there any solution for this problem? we'v got the same problem on a skylake i5. with xorg.conf and intel driver it's not working only case are usable.

we just test it on bar metal Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz:

- with 7.3 it's working
- after we update 7.3 to 7.4 BUT yum --exclude=xorg-x11-* it's still working
- after full updated to 7.4 it's no longer working

so IMHO it's a regression in 7.4 and noting to do with virtualization.

is there any plane to fix it in 7.4?

(In reply to Terrence Xu from comment #8)
> The default driver for skylake 2D gfx driver for 7.4 use mode setting or
> Intel 2D gfx driver is not important, rhel7.4 should support both mode
> setting and Intel 2D gfx driver, or it will make some confuse for end user
> that why Intel 2D gfx driver support Broadwell but not support Skylake.
> At least the newest xorg-intel-driver is a regression and we must fix it
> before release.

it seems that this regression was not fixed before release even it was a known regression half year before the release:-(

is there any solution workaround or even any kind of patch to fix it? I even patch the official rh's xorg package if someone can point me to the right patches.

thanks in advance.

Would be nice to at least get some feedback in regard to this matter. Personally, I'm set in my ways to re-install to 7.3, as it's not just graphics that isn't working well (no intention to take this discussion astray).

Namely, the power saving features no longer work - laptop cannot sustain 3h of uptime, let alone 8+ before the upgrade to 7.4 packages - and powertop tuning doesn't seem to help as it used to. This made me suspect there's a problem with linux-firmware package, or the kernel(s), but downgrading either/both didn't help.

I realized we're just a few freaks running server OS on laptops (or the like), and this doesn't affect the "general population". Still, it'd be invaluable to get some professional advice, as this is my production platform, and my debugging capabilities are limited.

finally i found the solution. it's already fixed in fedora:
https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/c/392c3eae5c4b542f39d6628def558397d387d87c?branch=master
with this patch the 7.4 src.rpm build and working properly.

anyway it's a sad thing that redhat's own patch makes it bad:-(

Hi all, until now we are still using the "modesetting" for workaround, at least it is not block our validation work. 
If the 2D driver issue can be fixed in 7.5 is better, or we will still use the workaround way.
Glad to see so many discussions these days. :)

Commit 392c3e Drop the patch to fail probe on skylake and newer, the xserver now

https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/c/392c3eae5c4b542f39d6628def558397d387d87c?branch=master

I'm also seeing a similar 7.3 -> 7.4 regression on an Intel "Skull Canyon" Skylake NUC (NUC6i7KYK) which may be related to this issue. (bare metal / no VM)  

I had to roll back the kernel and xorg-x11-* packages to get Xorg to work.

Paul what is the purpose of need_info?

You can use newer version of xorg-x11-drv-intel driver, especially backported from Fedora.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1541030
Backported driver: https://copr.fedorainfracloud.org/coprs/scx/xorg-x11-drv-intel/
20-intel.conf: http://wklej.org/hash/f9f24bb6a85/txt/

(In reply to Tomas Pelka from comment #25)
> Paul what is the purpose of need_info?

Tomasz: given comment #22, I was wondering status of this BZ (backport of the patch identified in comment #22).  Also, wondering how testing of that might be proceeding.

Given comment #26, seems to imply a fix is in the works.  Still a question if the comment #22 fix will make it to rhel 7.5.

(In reply to Paul Lai from comment #27)
> (In reply to Tomas Pelka from comment #25)
> > Paul what is the purpose of need_info?
> 
> Tomasz: given comment #22, I was wondering status of this BZ (backport of
> the patch identified in comment #22).  Also, wondering how testing of that
> might be proceeding.
> 
> Given comment #26, seems to imply a fix is in the works.  Still a question
> if the comment #22 fix will make it to rhel 7.5.

Please read my comment here: https://bugzilla.redhat.com/show_bug.cgi?id=1541030#c6

Created attachment 1389814 [details]
xorg-x11-drv-intel-2.99.917-31.20160929.el7.src.rpm

This issue cannot be reproduced with the RHEL-7.5 Snapshot1 ISO.

(In reply to Terrence Xu from comment #30)
> This issue cannot be reproduced with the RHEL-7.5 Snapshot1 ISO.

I checked while ago and I can confirm the same, moving to verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0736