Bug 1635747 - Switching users in GNOME session is starting new X servers for the user, and a user logout is making it unusable.
Summary: Switching users in GNOME session is starting new X servers for the user, and ...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-server
Version: 7.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: Desktop QE
Depends On: 1489977 1636460
Blocks: 1571842 1607454 1707454 1588877 1597339 1632807 1637651 1640918
TreeView+ depends on / blocked
Reported: 2018-10-03 15:09 UTC by Ray Strode [halfline]
Modified: 2019-08-06 12:42 UTC (History)
16 users (show)

Fixed In Version: xorg-x11-server-1.20.1-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1489977
: 1637651 1640918 (view as bug list)
Last Closed: 2019-08-06 12:41:58 UTC
Target Upstream Version:

Attachments (Terms of Use)
backtrace (9.86 KB, text/plain)
2018-10-17 14:57 UTC, Jiri Koten
no flags Details
Xorg.1.log (53.36 KB, text/plain)
2018-10-17 14:58 UTC, Jiri Koten
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3559061 None None None 2018-10-03 15:09:37 UTC
Red Hat Product Errata RHSA-2019:2079 None None None 2019-08-06 12:42:30 UTC

Description Ray Strode [halfline] 2018-10-03 15:09:38 UTC
+++ This bug was initially created as a clone of Bug #1489977 +++
--- Additional comment from amit yadav on 2018-09-27 13:29:45 EDT ---

(In reply to Tomas Pelka from comment #17)
> (In reply to Ray Strode [halfline] from comment #16)
> > this works fine for me with:
> > 
> > xorg-x11-server-Xorg-1.20.1-2.el7
> > and
> > gdm-3.28.2-9.el7
> > 
> > can you retry with at least those versions? You might be hitting bug 1632807
> Note that we need the feedback asap, I need to decide what to do with this
> bz tomorrow.

Sorry for delay in response. I was on leave so I couldn't update the bug.

I just tried it on my test system with latest packages. The issue is still reproducible.

journal logs and Xorg.0.log files attached. 

time: Sep 27 13:28

--- Additional comment from Ray Strode [halfline] on 2018-09-28 06:34:30 EDT ---

hmm i just noticed youre using qxl, let me see if i can reproduce with that.  youre getting permission denied not einval so maybe a different issue. hopefully i can reproduce when i get to work

--- Additional comment from Ray Strode [halfline] on 2018-09-28 17:00:13 EDT ---

i was able to reproduce with qxl, still investigating. i won't have an update until late monday probably.

--- Additional comment from Ray Strode [halfline] on 2018-10-01 16:58:10 EDT ---

i hit a number of problems today that prevented me from being able to fully investigate this issue.

The problem seems to be a kernel issue (drm master ownership, potentially related to atomic modesetting patches, see bug 1632807).

I hope to have a clearer picture tomorrow, once my kernel build finishes and i can add some debugging calls to the drm module.

--- Additional comment from Ray Strode [halfline] on 2018-10-03 10:35 EDT ---

So, this doesn't seem to be a duplicate of bug 1632807 after all.

I instrumented the kernel to highlight when master was getting dropped and set and we were clearly failing to call drop master in the existing X server before doing set master in the switched X server. master ownership is important for being able to set the screen resolution and display contents on screen.

The problem is that when the X server is killed it does a VT switch back to the VT it was started from.  Normally switching to another VT leads to master getting dropped, but in this termination case, they don't, since the event loop is finished before the VT switch is initiated.

Most drivers workaround this problem by having this sort of code in their CloseScreen hook:

if (pScrn->LeaveVT)
     pScrn->LeaveVT (...);

This LeaveVT call, simulates the leave vt event that would come in if the event loop were still active.

I say most drivers, but not all.  The QXL driver fails to implement this workaround.  The above patch fixes the issue for me.

Doing a quick search, though, the vmware driver also fails to call LeaveVT from CloseScreen, so I think, maybe, a better approach would be to call the LeaveVT hook from somewhere more generic like xf86CrtcCloseScreen or maybe a new xf86 ddx CloseScreen hook.

--- Additional comment from Ray Strode [halfline] on 2018-10-03 10:38:19 EDT ---

btw, i think we should move this bug back to VERIFIED, and clone for the qxl issue, since it really is separate, so I'll do that shortly.

Comment 1 Ray Strode [halfline] 2018-10-03 15:17:34 UTC
so one problem with attachment 1490121 [details] is LeaveVT is called after CloseScreen.  This isn't necessarily a "safe" thing to do, since CloseScreen can potentially change the LeaveVT handler.  It would be better to call it before CloseScreen.

Still, I've discussed this problem with Adam somewhat, and he believes this can be fixed centrally in the xserver, so attachment 1490121 [details] probably won't be needed, regardless.

Comment 5 Jiri Koten 2018-10-17 14:57:47 UTC
Created attachment 1494891 [details]

Comment 6 Jiri Koten 2018-10-17 14:58:52 UTC
Created attachment 1494892 [details]

Comment 7 Jiri Koten 2018-10-17 15:01:28 UTC
Pkgs tested:


Comment 11 errata-xmlrpc 2019-08-06 12:41:58 UTC
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.


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