Hide Forgot
Description of problem: Sometimes (but frequently in last days) after a screensaver intervention, when pressing a key the monitor is enabled (the backlight is switched on), but the screen remains black. Changing vt is possible, and is possible to login with another user, but the original user vt is still black. Killing the gdm-session-worker closes the user session and is possible again to login even with the old user. Version-Release number of selected component (if applicable): How reproducible: Sometimes, apparently not when the screensaver is in for a short time. Steps to Reproduce: 1.Logon 2.leave the computer alone for a bit, wait for the screensaver 3.push a key Actual results: look disappointed to the black screen Expected results: start to work again on your old session Additional info:
Just a little update: I enabled "WaylandEnable=false" in /etc/gdm/custom.conf, but the problem is still present. Sometimes the problem raises immediately after the screen locks, sometimes the screen lock works... Looking in Internet, I found someone who says that gdm is buggy, and suggests to replace it with something else, like kdm. I'm sorry, I set severity to "urgent", but maybe is a bit too much, but is at least "high": my work is really disrupted... GT
Tried older kernel (4.4.6-300.fc23.x86_64), same problem. Apparently the X server (/usr/libexec/Xorg) grows in memory to near the size of the physical memory. I'll do more checks. GT
Ok, maybe I found something.... this is ps axuwf just after login: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND gturchi 27517 0.0 0.0 450972 10556 tty2 Ssl+ 23:09 0:00 \_ /usr/libexec/gdm-x-session --run-script gnome-session gturchi 27523 4.6 0.4 579344 80944 tty2 Sl+ 23:09 0:04 \_ /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1144/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 this is the same command after the problem (entering as another user): USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND gturchi 2372 0.0 0.0 450972 2284 tty2 Ssl+ 08:28 0:00 | \_ /usr/libexec/gdm-x-session --run-script gnome-session gturchi 2378 1.2 89.5 17445384 14611668 tty2 Sl+ 08:28 11:16 | \_ /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1144/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 The Xorg size (RSS) has grown from 80944 to 14611668. Houston, we have a problem... GT
With the last kernel the problem is still present (4.4.8-300.fc23.x86_64). Done some check with xrestop, nothing to report: even when the Xorg "exploded" the xrestop values remained normal.
With last f23 updates (kernel 4.5.7-202.fc23.x86_64) the problem is still present. Had to downgrade xorg-x11-server-Xorg.x86_64 to first release to be able to work. I'm very concerned that, upgrading to f24, In case of problems I can't even downgrade...
If you're worried about upgrading, then you can try the F24 livecd to see if this is fixed there. Other then that some more info would be useful, what hardware is this, which desktop environment are you using, please attach dmesg and Xorg logs, etc.
Created attachment 1180231 [details] dmidecode dmidecode output
My environment is a standard gnome shell from f23. I'll attach hardware description and logs.
Created attachment 1180232 [details] dmesg dmesg output (under standard conditions, I'll post dmesg output as soon as the problem happens again)
Created attachment 1180233 [details] Xorg.0.log Xorg log. Under standard conditions.
Created attachment 1180780 [details] dmesg, after hang dmesg dump after hang (black screen, switch to text vt, login, dump)
Created attachment 1180781 [details] Xorg.0.log after hang Xorg.0.log copy after hang (black screen, switch to text vt, login, copy)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.