Created attachment 1484371 [details]
system journal

This could be a variation on what I'm seeing in bug 1629409, except that is a Wayland case.

Hello, I have tested this bug on my machine, and not only it behaves like this, it also crashes, when I switch to a VT (CTRL-ALT-F3) and back.

My machine is Lenovo ThinkPad T460s with 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07).

Versions of software:

qtile-0.12.0-1.fc29.x86_64
xorg-x11-server-Xorg-1.20.1-2.fc29.x86_64
mesa-dri-drivers-18.2.0-1.fc29.x86_64
mesa-dri-drivers-18.2.0-0.3.fc29.i686
libdrm-2.4.93-1.fc29.x86_64
libdrm-2.4.93-1.fc29.i686
kernel-4.18.7-300.fc29.x86_64

Happens also on my T470s:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)

While in Gnome Xorg session, after I switched to VT, i didn't see the login prompt, only some graphical artifacts on enabled (external) display. After switching back to VT 2, where I expected Gnome Session, I've seen only grayish gdm background and I assume gdm's login prompt was on internal (disabled) display. Suspending and resuming the pc ended up with showing gdm, but the session has crashed.

Same issue happened also on AMD-powered machine even without disabling any of the displays, VT worked fine without any artifacts:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f] (rev d4)

This does not happen on Wayland session at all.

OK, so to summarize, we now have 4 different computers affected by what seems to be the same issue. The PC must always have at least 2 displays and running in an X11 session, but the configuration to hit this differs slightly:

Intel 620:
- internal laptop display must be disabled, otherwise it doesn't crash
- on Frantisek Zatloukal's laptop, the VT3 text tty is not visible anywhere, whereas on my laptop it displays properly at least on the laptop display

Intel 520:
- the crash occurs always, both if internal laptop display is enabled or disabled

Radeon R7:
- the crash occurs when both external displays are enabled (this is a desktop, it doesn't have a laptop screen)

This seems to be widespread enough to get discussed in a blocker meeting, I think. The criterion itself might be tricky, because we don't have a "switching VTs must work" criterion, we just have "all virtual consoles intended to provide a working login prompt must do so" [1] and it depends what "working" means, whether it needs to survive a VT switch or not. However, I think switching VTs is quite common among power users that this should get considered.

[1] https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria#Expected_installed_system_boot_behavior

Moreover, if my laptop lid is closed as opposed to open (and disabled), my session still crashes after a switch to tty3 and back (and the traceback still looks the same), but I'm *not* put back to gdm. Instead, I see a blank screen with a cursor, and I no longer do anything (switch ttys). I think it then probably hits bug 1629409. The only help is hard reset or alt+sysrq+e (terminate all processes). So this variation is even more difficult for the user.

I do see this in Kamil's log:

Sep 18 14:04:13 phoenix kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

possibly relevant...

It'd be nice if someone could get a backtrace from the crashing component, though...

Discussed during the 2018-09-24 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" was made as this is specific to X11 and multiple monitors, and it seems like it won't be commonly-enough encountered to constitute a blocker. We will revisit if new information emerges.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-24/f29-blocker-review.2018-09-24-16.05.txt

I think this is the most important error line:

/usr/libexec/gdm-x-session[1945]: (EE) modeset(0): failed to set mode: Invalid argument

(In reply to Adam Williamson from comment #8)
> It'd be nice if someone could get a backtrace from the crashing component,
> though...

There is no crash. Neither abrt not coredumpctl detect anything crashing.

In the attached journal, I can see various errors from extensions that has not been ported to 3.30. Does disabling disabling them make any difference?

Created attachment 1490447 [details]
system journal without extensions

Hello Jonas. Sorry, I uploaded a journal without extensions active. The problem hasn't changed.

kparal: agreed, that looks like the critical line. That comes from X.org xserver hw/xfree86/drivers/modesetting/drmmode_display.c drmmode_set_mode_major():

        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;

drmmode_crtc_set_mode does more or less what you'd expect from the name, gets the mode information from the 'crtc' and tries to set it. It can fail in several ways. It might be interesting to know the 'crtc', 'mode', 'x' and 'y' that are getting passed to drmmode_set_mode_major in this case...

I think I have a similar problem that the one described here.
Please tell me if I can provide any useful log.


Description of problem:
Since Fedora 29 upgrade i3wm session does not start correctly.

After login in from GDM screen remains gray.
If, after a couple of seconds, I press Control-Shift-F7 to go to a black text console, then I can use Control-Shift-Fx to get the i3wm session correctly loaded. Sometimes it's in F4, other in F6, etc.

Wayland GNOME or Sway don't have this problem.
I'm not completely sure but I think it happened as well with GNOME XOrg the first days after F29 upgrade (xorg-x11-server-Xorg v1.20.1?), but not nowdays, now GNOME XOrg starts ok.

After I've found my i3wm session, if I switch to text VT or open a graphic session from GDM with another user I can't recover my session, it does not appear in any Control-Shift-Fx, but processes keep running in background.
Sometimes, if I lock the session (using i3lock) before switching I can recover it from the same Control-Shift-Fx where it was running.

I've observed that the problem does not appear with only 1 monitor connected to computer, but always with 2 monitors.


The log says:
No crashes appear in logs. These are the only related entries:
Dec 07 20:51:42 inigo.katxi.org /usr/libexec/gdm-x-session[1292]: (EE) open /dev/fb0: Permission denied
...
Dec 07 20:51:43 inigo.katxi.org /usr/libexec/gdm-x-session[1292]: (EE) modeset(0): failed to set mode: Invalid argument


My hardware is:
Fujitsu Esprimo Q556 - It's a compact computer, I think internals have much in common with laptops
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06) - Intel(R) HD Graphics 530 (Skylake GT2)
Monitor 1: Viewsonic VX2753MH-LED
Monitor 2: ASUS VC239HE
Both monitors have same native resolution 1920x1080.


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.20.3-1.fc29.x86_64


How reproducible:
100%


Steps to Reproduce:
1. boot with computer and 2 displays attached
2. log in to i3wm session


Additional info:
This problem happens since the first time after F29 upgrade, which I did the same day it was released.
Since then many packages have changed: kernel, mesa libs, etc. No differences. I even tested with old F28 kernel version.

Also, don't know if it's related, but since F29 upgrade when I connect to a remote virtual desktop with VMware Horizon Client (VMware VDI technology) remote desktop window remains black and I can't interact with any other window in the i3wm desktop. I think that if I click blindly (f.e. in a program icon), app opens, but local linux screen is not updated.
This does not happen when running VMware Horizon Client from GNOME (Xorg and Wayland) or Sway. I think it also happened with GNOME Xorg first days after upgrade.

I have the same issue when using three monitors (laptop + HDMI + USB C) on Lenovo T480 running Fedora 29.

My hardware:

00:02.0 VGA compatible controller: Intel Corporation Device 3e92 (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 8694
	Flags: bus master, fast devsel, latency 0, IRQ 125
	Memory at a0000000 (64-bit, non-prefetchable) [size=16M]
	Memory at 90000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 4000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [100] Process Address Space ID (PASID)
	Capabilities: [200] Address Translation Service (ATS)
	Capabilities: [300] Page Request Interface (PRI)
	Kernel driver in use: i915
	Kernel modules: i915

It is a desktop system with dual monitors.

Hi,

After many tests I think I've got to make the problem disappear!

Create the file "/etc/X11/xorg.conf.d/20-intel.conf" with these contents, log out and log in again (or reboot):

Section "Device"
	Identifier "Intel Graphics"
	Driver "intel"
EndSection


Hope it helps,
Iñigo

Thank you Iñigo! Your solution works for me and this problem was such a pain. Hardware: Dell XPS 9350, Intel HD Graphics 520, Fedora 29.

I was seeing this problem not only when connecting/disconnecting external monitors but also upon waking from sleep when a monitor had been removed/added during the sleep.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I have tested the same use case as in comment 0 with Fedora 31, and GNOME no longer crashes when switching VTs.

Closing as per comment 21.