Bug 1630367 - gnome session crashes after a VT switch (on X11 with multiple monitors)
Summary: gnome session crashes after a VT switch (on X11 with multiple monitors)
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-18 13:19 UTC by Kamil Páral
Modified: 2019-08-09 09:07 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
system journal (453.95 KB, text/plain)
2018-09-18 13:20 UTC, Kamil Páral
no flags Details
system journal without extensions (557.48 KB, text/plain)
2018-10-04 10:02 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2018-09-18 13:19:18 UTC
Description of problem:
If I switch to text VT and back to my gnome session, the session crashes and I'm put back to gdm. 

This happens in this *exact* configuration:
- a laptop with lid opened
- a single external display attached (tested two different ones, one with DP and one with HDMI, happens for both of them)
- you log in into gnome X11 session (it works on Wayland)
- your session is configured to disable the internal laptop display and only use the external display

The log says:
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:82
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:83
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:68
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:69
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:67
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:73
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:66
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:72
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 13:71
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) systemd-logind: got resume for 226:0
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) AIGLX: Resuming AIGLX clients after VT switch
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE) modeset(0): failed to set mode: Invalid argument
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE)
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: Fatal server error:
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE) EnterVT failed for screen 0
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE)
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: Please consult the Fedora Project support
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]:          at http://wiki.x.org
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]:  for help.
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE) Please also check the log file at "/home/kparal/.local/share/xorg/Xorg.0.log" for additional information.
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE)
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (II) AIGLX: Suspending AIGLX clients for VT switch
Sep 18 14:04:22 phoenix kernel: rfkill: input handler disabled
Sep 18 14:04:22 phoenix /usr/libexec/gdm-x-session[1945]: (EE) Server terminated with error (1). Closing log file.

My hardware is:
Thinkpad T480s (plus the Lenovo thunderbolt dock with outputs for external monitors)
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07)

I have tested this with another T480s belonging to my colleague (Lukas Brabec), it behaves the same (tested with two external displays). I have not tested other laptops with different Intel or non-Intel graphics.

Version-Release number of selected component (if applicable):
gnome-shell-3.30.0-3.fc29.x86_64
gnome-session-3.30.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-1.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

How reproducible:
100%

Steps to Reproduce:
1. boot with a laptop and one external display attached
2. log in to X11 session
3. disable internal display
4. switch to tty3 (text)
5. switch back to tty2 (your session)
6. see that you get back to gdm and your session is gone

Additional info:
Side note: There is a bit weird behavior during the switch. The laptop display is disabled in my session. After I switch to VT3, it gets enabled again (that's probably expected, I'm no longer in my session). I'm supposed to see text prompt on both my displays. The laptop display is always working fine. But the external monitor is not. The DP monitor says something like "no signal". If I use the HDMI monitor instead, it shows the prompt fine, but there are graphical artifacts on the screen (occasional white lines appearing and disappearing). After I switch back to my session (VT2), the laptop display gets disabled correctly, my session crashes, and gdm gets shown on the external display. Overall, there seems to be some driver issue preventing the external displays from working correctly when in text VT. I see some errors like this in the journal:
Sep 18 14:04:13 phoenix kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
I'm not sure whether this is relevant to this bug report or not.

Comment 1 Kamil Páral 2018-09-18 13:20:39 UTC
Created attachment 1484371 [details]
system journal

Comment 2 Chris Murphy 2018-09-18 14:32:15 UTC
This could be a variation on what I'm seeing in bug 1629409, except that is a Wayland case.

Comment 3 Lukas Ruzicka 2018-09-18 15:07:36 UTC
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

Comment 4 František Zatloukal 2018-09-18 16:50:15 UTC
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.

Comment 5 Kamil Páral 2018-09-19 08:10:46 UTC
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

Comment 6 Kamil Páral 2018-09-19 10:23:27 UTC
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.

Comment 7 Adam Williamson 2018-09-19 21:19:48 UTC
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...

Comment 8 Adam Williamson 2018-09-24 18:21:57 UTC
It'd be nice if someone could get a backtrace from the crashing component, though...

Comment 9 Geoffrey Marr 2018-09-24 19:37:37 UTC
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

Comment 10 Kamil Páral 2018-09-25 08:00:19 UTC
I think this is the most important error line:

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

Comment 11 Kamil Páral 2018-09-25 08:16:53 UTC
(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.

Comment 12 Jonas Ådahl 2018-10-04 09:39:57 UTC
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?

Comment 13 Kamil Páral 2018-10-04 10:02:26 UTC
Created attachment 1490447 [details]
system journal without extensions

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

Comment 14 Adam Williamson 2018-10-04 18:52:39 UTC
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...

Comment 15 Iñigo Serna 2018-12-07 21:03:19 UTC
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.

Comment 16 John Shojaei 2019-01-01 14:42:17 UTC
I have the same issue when using three monitors (laptop + HDMI + USB C) on Lenovo T480 running Fedora 29.

Comment 17 Hin-Tak Leung 2019-02-08 18:04:57 UTC
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.

Comment 18 Iñigo Serna 2019-02-10 18:37:36 UTC
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

Comment 19 Ian 2019-02-14 15:42:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.