Is anyone else experiencing this (see thread title)? This thread is a knee-jerk reaction/placeholder, as I haven’t even begun diagnosing (i.e. starting with looking at the X log for the session that gets killed).
I note that someone else was having problems a while back, but I think it was working fine for me then (though I may not have even checked, I just don’t remember) See https://forums.opensuse.org/showthread.php/520775-Graphical-session-randomly-dies … in that case, it was a random occurence, whereas I’m seeing 100% occurrence/reproducibility … plus, different drivers involved, but still, wondering if there is a common element involved in the X server
I note that it was mentioned on Fri that this behaviour has been observed in factory. I don’t see any other references or discussion about it – see: https://lists.opensuse.org/opensuse-factory/2016-12/msg00151.html … in that case, its discussing the forthcoming move to v1.19 of the X server … as no other info is given, I don’t know if anyone is experiencing it on v1.18.4 like me
Looks like this is a corner case issue → use of two graphics adapters.
Looking at the Xorg log, the second adapter generates an error slightly after the switch from console back into the X session occurs, resulting in termination of the X session and a switch back to console (effectively, at that point, the SDDM login):
82.156] (II) AIGLX: Suspending AIGLX clients for VT switch
87.944] (II) AIGLX: Resuming AIGLX clients after VT switch
...
88.091] (EE) RADEON(G0): failed to set mode: No space left on device
88.091] (EE)
Fatal server error:
88.091] (EE) EnterVT failed for gpu screen 0
...
88.092] (II) AIGLX: Suspending AIGLX clients for VT switch
88.106] (EE) Server terminated with error (1). Closing log file.
I think its related to EXA. The error doesn’t occur when using the modesetting driver (note: modesetting uses glamor) … sidebar observation: but man, in this scenario, was the opengl performance ever **** … (though, I suspect that the reason for that will be arb’ed away via a number of the changes that await in the pending X server v1.19 upgrade).
The current version of radeon_drv.so (available with TW) doesn’t yet support glamor by default (i.e. it still utilizes EXA) … (the next v7.8.x dot release of the driver should rectify that). So, currently, in order to use glamor with the xorg radeon driver, you have to manually config it … typically this can be easily done via a xorg.conf.d snipet file, but in this case, because of the multiple adapters used, a full-fledged xorg.conf file is required. I simply didn’t have time to draw one up and then test.
As a side effect of looking into this, the investigation has also exposed to me that one of my monitors (hdmi connected) is, well, not what I’d call spamming the xorg log, but its definitely squawking a bit (with both radeon and modesetting) >:(
It’s not completely clear what you are experiencing.
Recently, with Plasma 5, I use CTRL-ALT-F1 to get to a console. I then discovered that CTRL-ALT-F7 got me back to a login screen, while CTRL-ALT-F2 got me back to my Plasma 5 session. (Or maybe I have those backward).
I assumed that this is because the login screen (from “gdm”) is running under “wayland” while the Plasma 5 session is under X.
Swtching between X session (Plasma) to Console & then back kills X session, dropping you to DM login
Like the vast majority of users, I log into a Desktop session. Desktops are, of course, run on top of a display server. In this case, I’m using an X server display. The destop that I’m running on the X session happens to be KDE/Plasma 5. And it is spun, by the system, on VT7
I then switch to console (CTRL-ALT-Fx … where, typically with openSUSE, x= 1-6 ).
at any point in time later on when I switch from the console (and it can be from anyone of the VTs) back to the X Session on VT7 (i.e. do so via CTRL-ALT-F7), what I discovered is that the VT switch is successful, as I do catch a glimpse of my Plasma desktop, but
resumption of that existing desktop session lasts for all of a fleeting second (hence why I only “catch a glimpse”) before the X Session terminates - a VT switch then occurs (VT7 -> VT1, if I’m not mistaken)
then on that Console, the Display Manager (SDDM in this case) is respun. It (the DM) then initiates a new X Session (which is done so back on VT7 (i.e. another VT switch occurs)) upon which the DM’s greeter screen (i.e. login screen) is launched.
Recently, with Plasma 5, I use CTRL-ALT-F1 to get to a console. I then discovered that CTRL-ALT-F7 got me back to a login screen, while CTRL-ALT-F2 got me back to my Plasma 5 session. (Or maybe I have those backward).
I assumed that this is because the login screen (from “gdm”) is running under “wayland” while the Plasma 5 session is under X.
You likely got it backward. By tradition, its usually VT7 upon which the desktop session will be spun. You have the interesting case of where a second, unique, display server is involved (gdm’s greeter running upon Wayland, from which and X session, with Plasma5 running on top of that, is spun… which makes for a whole lot of fun with VTs ).
In any regard, I hope my colour coordinated description above helps provides clarity and clears up any confusion
Can throw that idea out the window… I tested with the radeon xorg driver using glamor and I get the same error … will have to dig a little deeper. Not sure if Dimstar’s comment (“Apparently there are some issues with switching between Text and GUI mode”) is related or not … (certainly sounds like it could be, but without more context, it remains vague on its own…and unfortunately, like I said earlier, I haven’t found other information pertaining to this yet).
The current version of radeon_drv.so (available with TW) doesn’t yet support glamor by default (i.e. it still utilizes EXA) … (the next v7.8.x dot release of the driver should rectify that). So, currently, in order to use glamor with the xorg radeon driver, you have to manually config it
true
typically this can be easily done via a xorg.conf.d snipet file, but in this case, because of the multiple adapters used, a full-fledged xorg.conf file is required.
Not true. It can be done with the snippet files too –> You list both adapters in the device file and then list both devices in the screen file.
I’m not seeing that. But maybe the use of “gdm” is different enough that I cannot compare.
Is it possible that this behavior is related to your particular video card?
I just rechecked. And I had it right.
CTRL-ALT-F1 to get a console. I logged in there as a different user.
CTRL-ALT-F2 took me back to my plasma 5 session
CTRL-ALT-F7 took me to a “gdm” login screen.
I then did CTRL-ALT-F1, and logged out that console session. I followed that with CTRL-ALT-F2 to resume my Plasma 5 session (about to run updates).
maybe the use of “gdm” is different enough that I cannot compare.
Is it possible that this behavior is related to your particular video card?
I’m pretty sure its just a corner case (two adapters) with the xorg radeon driver … I’m not sure when it (normal functionality) stopped working … but, I assure you it worked just fine in the past. And, as I mentioned yesterday, the generic modesetting driver worked as well in this corner case usage scenario. So, I’m looking at you radeon
v7.8 of the radeon xorg driver (released in TW on nov 17th, or something like that) brought about a number of changes, as well as prepping the driver for v1.19 of the X server … v1.19 of X (which was released about mid Nov by Xorg) still hasn’t been released in TW, as apparently they’ve been having some difficulties with it in Factory. As I can’t find any other info on the ML’s about this, I can only go by the tidbits:
There is a whole lot of nice stuff queued up in v1.19 that I’m awaiting.
I just rechecked. And I had it right.
CTRL-ALT-F1 to get a console. I logged in there as a different user.
CTRL-ALT-F2 took me back to my plasma 5 session
CTRL-ALT-F7 took me to a “gdm” login screen.
I then did CTRL-ALT-F1, and logged out that console session. I followed that with CTRL-ALT-F2 to resume my Plasma 5 session (about to run updates).
Ahh, thanks. … well, in many regards that makes sense too … VT7 is the traditional goto console … in this case Wayland is being spun up on it (and the gdm greeter on top of that) … its interesting that the next display server (X/Plasma) is spun on VT2, as:
In a “normal” case where X/Desktop is started on VT7, if you’d start another X session, you’d find it put on VT8 … Curious where it’d be put in your case (I’d bet 8, so that the user is still left with VT1 and 3-6)
I don’t think the upstream issues are linked to my problem. I still haven’t had time to troubleshoot it much, but I did find that I’m also having an error on the same adapter (that suffers the error that causes the the X server to terminate) with relation to the radeon driver’s dpm (dynamic power management). Ugh. Those two points seem much more likely connected then anything else.
Wondering out loud to myself … I wonder if its just the hdmi cable … I also note that I occasionally suffer audio dropouts on this very same … more investigation need. (PS - these last issues are connected to “the good” adapter, and not the trouble maker discussed above)
Just a note to this aside discussion: If I log into Wayland/Plasma, it (the Wayland session) gets spun on VT2 as well. From Wayland, I can VT switch to my heart’s content, whereas the second I go back to VT7 (on which an X session is running), the X server terminates.
And that makes perfect sense as to why I can (VT switch to my heart’s content) with the one and not the other: there’s no DDX (Xorg driver) involved in the case of Wayland.
[Another sidenote: As for Wayland/Plasma, its still buggy with multi-monitors and/or mulit-adapters:
[ul]
[li]immediately when I log in I receive a notice that KDE Accessibility Tool (Kaccess) has crashed … (note: I don’t use accessibility, so this is just the desktop invoking something on its own) [/li][li]still getting lots of visual glitching going on [/li][li]I have to acquaint myself with how to do Prime like stuff on Wayland … or find out if a solution has even been implemented yet for that matter [/li][li]when I try to logout/reboot/etc, kmserver-logout crashes … kinda gives me that Hotel California feel/sentiment to it –> “You can check out any time you like[/li]But you can never leave!” ]
[/ul]
).