Bug 1382001 - Logging out from second user after switching users kills first user's session (with xorg-x11-drv-qxl at least)
Summary: Logging out from second user after switching users kills first user's session...
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-qxl
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Alon Levy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Keywords: CommonBugs, Triaged
Depends On:
Blocks: F25FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2016-10-05 13:44 UTC by Petr Schindler
Modified: 2017-12-12 10:03 UTC (History)
22 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-12-12 10:03:37 UTC


Attachments (Terms of Use)
all sessions killed - journal (276.98 KB, text/plain)
2016-10-20 09:53 UTC, Kamil Páral
no flags Details
black screen instead of login screen - journal (330.99 KB, text/plain)
2016-10-20 09:56 UTC, Kamil Páral
no flags Details
rpm -qa output (51.88 KB, text/plain)
2016-10-20 09:56 UTC, Kamil Páral
no flags Details
Xorg.0.log.old of 'crashed' user1 session (21.28 KB, text/plain)
2016-11-01 16:53 UTC, Oliver Henshaw
no flags Details
Xorg.1.log of logged out user2 session. (19.58 KB, text/plain)
2016-11-01 16:57 UTC, Oliver Henshaw
no flags Details
User session with a greeter as a window (255.31 KB, image/png)
2016-11-08 14:42 UTC, Martin Bříza
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 99102 None None None 2016-12-16 14:14 UTC
Red Hat Bugzilla 1392654 None None None Never

Internal Trackers: 1392654

Description Petr Schindler 2016-10-05 13:44:18 UTC
Description of problem:
I created two users and try to login with both of them and then to switch between them.

Firstly I login as first user. Then I go to Menu->Leave->Switch User - then I create new session and login and second user. Then I'd like to login back as first user, but after I click on Switch user and then again on Switch the desktop freezes.

System itself works further but you can't switch to another virtual terminal. But if you are sshd to the machine you can work with it. But if you have no other pc you have to restart machine, which means to lose both sessions.

I also tried to logoff from first user and login to the second and then logoff and login as first user again. This work flow works fine (but sessions are terminated).

In one case (just one so far) it happened to me that after some time (about 10 minutes) the active session (the one where it froze) got locked. I could unlock as usually and then the switching worked fine (I could switch between both users without problems). But I wasn't able to reproduce this behaviour.

Version-Release number of selected component (if applicable):
sddm-0.13.0-7.fc25.x86_64

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
I propose this as a Final blocker. Because Switching user button can be found on menu this violates the final criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. "

Comment 1 Geoffrey Marr 2016-10-17 19:49:52 UTC
Discussed during the 2016-10-17 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" as 'switch user' is an offered mechanism, with 1184933 as precedent.

Please note, we don't require this functionality to be in Fedora so if the decision is made to remove or disable this from Fedora, we will accept that as an appropriate fix. Also, if the fix cannot be made in time for release, please let us know so we can decide what to do from there.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-17/f25-blocker-review.2016-10-17-16.02.txt

Comment 2 Martin Bříza 2016-10-20 08:19:21 UTC
Does anybody else exhibit this issue? I wasn't able to reproduce this bug when I tried it in F25 Beta Live image.
I added one user, created a new session from the session picker for him and I can switch freely from one to another without a problem.

Comment 3 Kamil Páral 2016-10-20 09:50:50 UTC
I tried with a fully updated F25 KDE in a VM (spice, qxl). It seems we received some KDE updates and it now behaves a bit differently. The versions I have:
sddm-0.14.0-1.fc25.x86_64
plasma-desktop-5.8.1-1.fc25.x86_64

User switching works fine for me. However, it seems that *logging out* is broken after you use user switching. I see two different scenarios. I'll attach logs and reproducer descriptions.

Comment 4 Kamil Páral 2016-10-20 09:53 UTC
Created attachment 1212417 [details]
all sessions killed - journal

All sessions are killed if user2 logs out. Reproducer:

1. boot the system
2. log in with user1
3. switch to user2
4. log out user2
5. see that user1 has been logged out (or killed) as well. TTY2 is now empty (should not be). If you try to log in as user1, you get a new session (you should get back to the existing session). Sometimes I see an error flash about "kmserver could not be started" or something like that right before login screen is shown.

Comment 5 Kamil Páral 2016-10-20 09:56 UTC
Created attachment 1212418 [details]
black screen instead of login screen - journal

Only black screen instead of login screen is shown, if user1 logs out. Reproducer:

1. boot the system
2. log in with user1
3. switch to user2
4. switch to user1
5. log out user1
6. see only black screen, no login screen. However, you can manually switch to TTY2 to see that user2 session is still running. So this is just the login screen being hung.

Comment 6 Kamil Páral 2016-10-20 09:56 UTC
Created attachment 1212419 [details]
rpm -qa output

Comment 7 Oliver Henshaw 2016-11-01 16:50:45 UTC
A bit more detail on comment #4, "All sessions are killed if user2 logs out", from a F24 VM install. It might be related to the qxl driver.

There's some more info in the Xorg.*.log.* files, which contain some error lines not present in the journal (for some reason). After seeing that user1's session has been killed, I logged in via ssh:

$ loginctl 
   SESSION        UID USER             SEAT            
        c3        993 sddm             seat0           
         7       1000 test                             
         5       1001 second           seat0           
         2       1000 test             seat0           

4 sessions listed.
$ loginctl show-session c3
Id=c3
User=993
Name=sddm
Timestamp=Tue 2016-11-01 16:09:31 GMT
TimestampMonotonic=504360655
VTNr=1
Seat=seat0
Display=:0
Remote=no
Service=sddm-greeter
Scope=session-c3.scope
Leader=2916
Audit=0
Type=x11
Class=greeter
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
$ loginctl 
   SESSION        UID USER             SEAT            
        c3        993 sddm             seat0           
         7       1000 test                             
         2       1000 test             seat0           

3 sessions listed

Looks like session 5 isn't cleaned up until loginctl tickles something. If I repeat "loginctl" then session 5 it still listed, only show-session seems to get it cleared up.

$ loginctl show-session 2
Id=2
User=1000
Name=test
Timestamp=Tue 2016-11-01 16:03:03 GMT
TimestampMonotonic=115473047
VTNr=1
Seat=seat0
Display=:0
Remote=no
Service=sddm
Desktop=KDE
Scope=session-2.scope
Leader=952
Audit=2
Type=x11
Class=user
Active=no
State=closing
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0

This is the user1 session that 'crashed' but it persists in the 'closing' state until something else logs in on vt1.

And here's the output of 'ps aux | grep test' (logged in at the terminal as root so that the ssh sessiion doesn't pollute it) - showing what remains of the session.

test       964  0.0  0.2  47596  5052 ?        Ss   16:03   0:00 /usr/lib/systemd/systemd --user
test       966  0.0  0.1 179676  3412 ?        S    16:03   0:00 (sd-pam)
test       979  0.0  0.1 117664  2868 ?        S    16:03   0:00 /bin/sh /usr/bin/startkde
test       997  0.1  0.2  59204  4892 ?        Ssl  16:03   0:01 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
test      1002  0.0  0.0  51316   580 ?        Ss   16:03   0:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "/usr/bin/startkde"
test      1075  0.0  0.6 328948 12428 ?        Sl   16:03   0:00 /usr/libexec/mission-control-5
test      1277  0.0  0.2 261832  5308 ?        Ssl  16:03   0:00 /usr/libexec/at-spi-bus-launcher
test      1281  0.0  0.2  58472  4156 ?        Sl   16:03   0:00 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
test      2898  0.0  0.2 146572  4884 ?        S    16:09   0:00 xmessage -geometry 500x100 Could not start ksmserver. Check your installation.
test      2907  0.0  1.6 651744 33220 ?        Sl   16:09   0:00 /usr/bin/kglobalaccel5
root      3267  0.0  0.0 117140   976 tty2     S+   16:19   0:00 grep --color=auto test

Xorg logs to follow.

Comment 8 Oliver Henshaw 2016-11-01 16:53 UTC
Created attachment 1216197 [details]
Xorg.0.log.old of 'crashed' user1 session

Note the warning (WW) and error (EE) lines.

Comment 9 Oliver Henshaw 2016-11-01 16:57 UTC
Created attachment 1216198 [details]
Xorg.1.log of logged out user2 session.

Note the "(EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied" etc. lines not present in Xorg.0.log.old

Comment 10 Oliver Henshaw 2016-11-01 17:31:14 UTC
Adding "-keeptty" to ServerArguments (and uncommenting it) in /etc/sddm.conf appears to solve the "All sessions are killed if user2 logs out" problem, at least so far.

(It doesn't seem to make any difference to comment #5 - "Only black screen instead of login screen is shown, if user1 logs out")

I also forgot to mention that I can't reproduce the problem with gdb attached (from a remote ssh session and with "handle" nostop for SIGIPE and SIGUSR1 - following https://www.x.org/wiki/Development/Documentation/ServerDebugging/) but could reliably reproduce it without gdb.

Comment 11 Martin Bříza 2016-11-02 08:28:54 UTC
There is the same report upstream here:
https://github.com/sddm/sddm/issues/653

Comment 12 Oliver Henshaw 2016-11-02 14:55:44 UTC
(In reply to Martin Bříza from comment #11)
> There is the same report upstream here:
> https://github.com/sddm/sddm/issues/653

Note that the upstream report describes comment #5, not comment #4 or comment #0.

Comment 13 Oliver Henshaw 2016-11-02 15:19:53 UTC
(In reply to Oliver Henshaw from comment #10)
> Adding "-keeptty" to ServerArguments (and uncommenting it) in /etc/sddm.conf
> appears to solve the "All sessions are killed if user2 logs out" problem, at
> least so far.
> 
Appears I spoke too soon. It doesn't make a difference today.

Comment 14 Martin Bříza 2016-11-02 16:36:10 UTC
I guess the problem described in Comment #5 Should be a separate bug. I attempted to fix that in this PR: https://github.com/sddm/sddm/pull/735

Comment 15 Martin Bříza 2016-11-02 16:47:57 UTC
A scratch build for testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725

Comment 16 Kamil Páral 2016-11-03 10:11:57 UTC
(In reply to Martin Bříza from comment #15)
> A scratch build for testing:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725

This fixes the problem mentioned in comment 5. It does not fix comment 4.

Comment 17 Martin Bříza 2016-11-03 17:12:24 UTC
The problem described in comment 4 doesn't happen on my box unfortunately.
Could probably be related to the fact you're in a VM. It's a bit late today but we're gonna test this tomorrow if we can find a solution.
From a glance at your journal it seems a bit odd the first user's session wasn't actually ended, as Oliver mentioned.

Comment 18 Oliver Henshaw 2016-11-03 22:04:25 UTC
I used perf to trace what processes use the DRM_SET_MASTER and DRM_DROP_MASTER syscalls. It looks like the Xorg on vt1 tries to get control of the DRM master before the Xorg on vt2 releases it - in fact there's no DRM_DROP_MASTER from the vt2 Xorg during logout so I think it only gets released when the fd is closed. I tried to add a filter for the close(2) event for the drm master fd in each process, but didn't get anything. Grepping the xf86-video-qxl code it doesn't look like drmClose is used in anything but an error path, so the fd is only closed when Xorg exits unless I'm missing something.

(It's a little more tricky to get the sys_exit_ioctl event corresponding to the DRM_SET_MASTER etc. calls so couldn't confirm the return values, but it does correlate to the error message in the Xorg.0.log.old)

Trying to do this with strace instead of perf makes the bug disappear - seems it's timing dependent.

1. Login as user1, create a new session for user2

2. Switch to a text terminal
# pgrep -fla Xorg
...
[shows xorg on vt1 is pid 4844, xorg on vt is pid 5885]
...

4. switch to a text terminal
# perf record -e syscalls:sys_enter_ioctl --filter 'cmd == 0x641e || cmd == 0x641f' -e sched:sched_process_exit --filter 'pid == 4844 || pid == 5885' -e sched:sched_process_free --filter 'pid == 4844 || pid == 5885' --call-graph dwarf -a -D 5000 -T -o perf_logouttwo_more.data sleep 120

5. logout from user2, wait two minutes and switch back to the text terminal
# perf script -i perf_logouttwo_more.data
Xorg  4844 [000]  3373.156721: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641e, arg: 0x00000000
                   f8b67 __GI___ioctl+0xffff005ba85ce007 (/usr/lib64/libc-2.23.so)
                    42b8 drmIoctl+0xffff005ba5e14028 (/usr/lib64/libdrm.so.2.4.0)
                   12888 qxl_enter_vt_kms+0xffff005bb2a2a028 (/usr/lib64/xorg/modules/drivers/qxl_drv.so)
                   b6d7d xf86RandR12EnterVT+0xffffffffff80007d (/usr/libexec/Xorg)
                   79940 xf86VTEnter+0xffffffffff800070 (/usr/libexec/Xorg)
                   3b94d WakeupHandler+0xffffffffff80006d (/usr/libexec/Xorg)
                  197fb9 WaitForSomething+0xffffffffff8001e9 (/usr/libexec/Xorg)
                   36bde Dispatch+0xffffffffff80008e (/usr/libexec/Xorg)
                   3add3 dix_main+0xffffffffff8003d3 (/usr/libexec/Xorg)
                   20731 __libc_start_main+0xffff005ba85ce0f1 (/usr/lib64/libc-2.23.so)
                   24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg)

Xorg  4844 [000]  3373.157012: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641f, arg: 0x00000000
                   f8b67 __GI___ioctl+0xffff005ba85ce007 (/usr/lib64/libc-2.23.so)
                    42b8 drmIoctl+0xffff005ba5e14028 (/usr/lib64/libdrm.so.2.4.0)
                   12902 qxl_leave_vt_kms+0xffff005bb2a2a032 (/usr/lib64/xorg/modules/drivers/qxl_drv.so)
                   7b91f AbortDDX+0xffffffffff80007f (/usr/libexec/Xorg)
                  1a79f2 AbortServer+0xffffffffff800022 (/usr/libexec/Xorg)
                  1a87fd [unknown] (/usr/libexec/Xorg)
                   79ad6 [unknown] (/usr/libexec/Xorg)
                   3b94d WakeupHandler+0xffffffffff80006d (/usr/libexec/Xorg)
                  197fb9 WaitForSomething+0xffffffffff8001e9 (/usr/libexec/Xorg)
                   36bde Dispatch+0xffffffffff80008e (/usr/libexec/Xorg)
                   3add3 dix_main+0xffffffffff8003d3 (/usr/libexec/Xorg)
                   20731 __libc_start_main+0xffff005ba85ce0f1 (/usr/lib64/libc-2.23.so)
                   24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg)                                                       
                                                                                                                             
Xorg  5885 [000]  3373.195317: sched:sched_process_exit: comm=Xorg pid=5885 prio=120                                         
            7fffa60a7b20 do_exit+0x80005a003560 ([kernel.kallsyms])                                                          
            7fffa60a8197 do_group_exit+0x80005a003047 ([kernel.kallsyms])                                                    
            7fffa60a8214 sys_exit_group+0x80005a003014 ([kernel.kallsyms])                                                   
            7fffa6006d52 do_syscall_64+0x80005a003062 ([kernel.kallsyms])                                                    
            7fffa67ef661 return_from_SYSCALL_64+0x80005a003000 ([kernel.kallsyms])

rcuos/0     9 [000]  3373.199799: sched:sched_process_free: comm=Xorg pid=5885 prio=120                                      
            7fffa60a6039 delayed_put_task_struct+0x80005a003069 ([kernel.kallsyms])                                          
            7fffa610b0fd rcu_nocb_kthread+0x80005a0032ad ([kernel.kallsyms])                                                 
            7fffa60c3638 kthread+0x80005a0030d8 ([kernel.kallsyms])                                                          
            7fffa67ef7bf ret_from_fork+0x80005a00301f ([kernel.kallsyms])                                                    
                                                                                                                             
Xorg  4844 [000]  3373.243504: sched:sched_process_exit: comm=Xorg pid=4844 prio=120
            7fffa60a7b20 do_exit+0x80005a003560 ([kernel.kallsyms])
            7fffa60a8197 do_group_exit+0x80005a003047 ([kernel.kallsyms])
            7fffa60a8214 sys_exit_group+0x80005a003014 ([kernel.kallsyms])
            7fffa6006d52 do_syscall_64+0x80005a003062 ([kernel.kallsyms])
            7fffa67ef661 return_from_SYSCALL_64+0x80005a003000 ([kernel.kallsyms])

rcuos/0     9 [000]  3373.257202: sched:sched_process_free: comm=Xorg pid=4844 prio=120
            7fffa60a6039 delayed_put_task_struct+0x80005a003069 ([kernel.kallsyms])
            7fffa610b0fd rcu_nocb_kthread+0x80005a0032ad ([kernel.kallsyms])
            7fffa60c3638 kthread+0x80005a0030d8 ([kernel.kallsyms])
            7fffa67ef7bf ret_from_fork+0x80005a00301f ([kernel.kallsyms])

Xorg  6878 [000]  3373.464285: syscalls:sys_enter_ioctl: fd: 0x00000015, cmd: 0x0000641e, arg: 0x00000000
                   f8b67 __GI___ioctl+0xffff0148328c8007 (/usr/lib64/libc-2.23.so)
                    42b8 drmIoctl+0xffff01483010e028 (/usr/lib64/libdrm.so.2.4.0)
                   12888 qxl_enter_vt_kms+0xffff01483cd24028 (/usr/lib64/xorg/modules/drivers/qxl_drv.so)
                   37141 AddScreen+0xffffffffff800101 (/usr/libexec/Xorg)
                   7cf72 InitOutput+0xffffffffff8003c2 (/usr/libexec/Xorg)
                   3abd6 dix_main+0xffffffffff8001d6 (/usr/libexec/Xorg)
                   20731 __libc_start_main+0xffff0148328c80f1 (/usr/lib64/libc-2.23.so)
                   24d59 _start+0xffffffffff800029 (/usr/libexec/Xorg)


xf86-video-ati for example seems to have more drmDropMaster() and drmClose() callers in cleanup/teardown paths. Seems like it might be a xf86-video-qxl bug? If so, I wonder why gdm users don't appear to see this. Might be because iirc they have per-user unprivileged Xorg processes and so they have some other code managing drm master transitions? Or perhaps they wait for the Xorg process to logout and terminate before switching vt? Or perhaps I'm misunderstanding the whole thing.

Comment 19 Adam Williamson 2016-11-07 21:17:17 UTC
This is now the final unaddressed blocker for fedora 25, and we have the go/no go meeting on Thursday. Is there any progress on a fix for this?

Comment 20 Adam Williamson 2016-11-07 21:51:23 UTC
Cc'ed ajax and airlied as this looks graphics-y, and Hans as he fixed a previous sddm vs. Qxl issue. Any ideas, guys?

When I get home I'll try and confirm whether this is qxl-only.

Comment 21 Adam Williamson 2016-11-08 00:53:41 UTC
I tested this here in a VM installed from Fedora-KDE-Live-x86_64-25-20161107.n.0.iso , with both qxl and vga adapters in the VM (using 'vga' results in the 'modeset' Xorg driver being used).

I cannot reproduce the initially-described issue, as Kamil and Martin both found.

Of Kamil's issues, I can reproduce "All sessions are killed if user2 logs out" (#c4) with qxl, but not with vga. I can reproduce "Only black screen instead of login screen is shown, if user1 logs out" (#c5) with both drivers.

The scratch build referenced in #c15 - http://koji.fedoraproject.org/koji/taskinfo?taskID=16279725 - does fix "Only black screen instead of login screen is shown, if user1 logs out" (#c5), with both drivers.

Since we have two separate issues here and a fix for one but not the other, I'm going to split this report for clarity, and (for now) apply the 'AcceptedBlocker' status to both. This report is now for the #c4 problem:

"All sessions are killed if user2 logs out. Reproducer:

1. boot the system
2. log in with user1
3. switch to user2
4. log out user2
5. see that user1 has been logged out (or killed) as well. TTY2 is now empty (should not be). If you try to log in as user1, you get a new session (you should get back to the existing session). Sometimes I see an error flash about "kmserver could not be started" or something like that right before login screen is shown."

I will file a new bug for the #c5 problem, and mark it POST since we appear to have a resolution for that. As things stand we are still not aware of any fix for this issue, though there are some PRs and commits upstream I want to look at.

Comment 22 Adam Williamson 2016-11-08 01:15:50 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1392654 covers #c5.

Comment 23 Adam Williamson 2016-11-08 01:58:50 UTC
So as a kinda hail mary, I tried a scratch build with this patch from upstream:

https://github.com/sddm/sddm/pull/724

which implements logind support for sddm. Result of that seems to be that 'Switch User' goes away from the kicker entirely. Which, I mean, technically resolves the issue, but I'm not sure want to just say 'what the hell, let's go with that', as it's a pretty drastic change. Just figured I'd try something.

Comment 24 Martin Bříza 2016-11-08 14:21:55 UTC
It may be worth noting that once the issue is triggered, further logins and logouts don't crash anything - everything seems to be fine.

Comment 25 Martin Bříza 2016-11-08 14:38:28 UTC
except Boxes, crashing all the time I try to log in afterwards
can that mean something? i guess the driver isn't dealing with it very well

Comment 26 Martin Bříza 2016-11-08 14:42 UTC
Created attachment 1218540 [details]
User session with a greeter as a window

Ok, I may be mistaken in the pre-previous comment - seems the session stays alive at some times. This time it even survived the start of the greeter. And took it as a window under kwin.

Comment 27 Martin Bříza 2016-11-08 16:27:29 UTC
Reassigning to xorg-x11-drv-qxl as it seems it's the root of the issue.
If it's not, I hope we'll be able to find a solution together faster.

Comment 28 Dennis Gilmore 2016-11-08 18:10:17 UTC
To add here, I did a install from Fedora-KDE-Live-x86_64-25-20161107.n.0.iso on a machine here.

I created two users, mary and foo, I had no issues switching between them using the "switch user" menu option. on logout from mary's session I was returned to the password screen to unlock foo's session. in my testing on bare metal I did not hit either bug

Comment 29 Adam Williamson 2016-11-08 20:27:56 UTC
I also just tried and could not reproduce this one on bare metal, so yeah, this one does look more and more to be tied to qxl.

Comment 30 Stephen Gallagher 2016-11-09 04:11:09 UTC
I'm a clear +1 FE if a fix is found.

On the other hand, user-switch is a less-common function (particularly under a VM), so I don't think it would pass the "last blocker at Go/No-Go" test (which it looks likely to actually have to face). So unless new information comes to light that says it happens outside of VMs, I'm going to vote -1 blocker.

Comment 31 Kamil Páral 2016-11-09 15:20:53 UTC
Petr Schindler tested this on a bare metal and it also seems to work OK there. So yeah, probably qxl related. And in that case I'm also for -1 blocker.

Comment 32 Martin Bříza 2016-11-11 12:34:56 UTC
One of the reasons GDM doesn't exhibit this could be in the fact it actually allocates VT1 for itself. SDDM leaves the VTs when a user session starts.

Comment 33 Petr Schindler 2016-11-11 13:38:29 UTC
Discussed at mini blocker review during go/no-go meeting [1].

We re-evaluated this bug. This bug was rejected as Final Blocker and accepted as Freeze Exception - this is downgraded to FE as it only affects the qxl driver, and we think user switching is fairly rare in VMs (and also rare in live sessions, so the combination makes a post-release fix acceptable)

[1] https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.html

Comment 34 Oliver Henshaw 2016-11-18 12:45:26 UTC
Actually it looks like sddm isn't involved in the VT switching at all, it all happens in the xserver.

In hw/xfree86/os-support/linux/lnx_init.c:xf86CloseConsole(), it calls the VT_SETMODE ioctl with VT.mode=VT_AUTO, so aiui the xserver isn't notified anymore when the VT changes. Then it "Perform[s] a switch back to the active VT when we were started". So the driver should have given up drm master by this point. As it hasn't, the xserver on the original active VT (VT1) falls over when it's notified of the VT switch and tries to use DRM_IOCTL_SET_MASTER.

Other video drivers seem to define an xf86FreeScreenProc which ends up calling drmClose. Perhaps this is what is missing in the qxl driver? (I'm not entirely sure if or when this is called on xserver teardown though).

Comment 35 Oliver Henshaw 2016-12-15 17:26:00 UTC
Reported upstream with a working (though not exhaustively tested) patch - https://bugs.freedesktop.org/show_bug.cgi?id=99102

Comment 36 Fedora End Of Life 2017-11-16 19:42:31 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

Comment 37 Fedora End Of Life 2017-12-12 10:03:37 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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