Description of problem: After suspending and resuming my laptop, I am offered the password unlock dialog. However, after entering the correct password, the screen is black and locked again for about one minute, showing only the top bar (which does not respond to any input). Then, magically, it unlocks and I can start working. However, if you don't know it / you want to start working right away, the only solution is to kill X11 or switch in a VTE and kill gnome-shell. Applies to Fedora 16, Verne, with all the packages updated. It happened all throughout this release cycle (since when I upgraded to Fedora 16, at the beginning of September). Version-Release number of selected component (if applicable): gnome-shell-3.2.0-2.fc16.x86_64 gnome-session-3.2.0-1.fc16.x86_64 gnome-screensaver-3.2.0-1.fc16.x86_64 How reproducible: Always. See steps below. Steps to Reproduce: 1. Close my laptop lid 2. Wait for the system to suspend 3. Re-open the lid 4. Move the mouse 5. Enter the (correct) password Actual results: gnome-shell unlocks, and I can start working right away. Expected results: The initial "locked" black screen you see before moving the mouse in step 4. is shown again, for about one minute. The system does not respond to any input from mouse or keyboard (although I can switch to a VTE, or kill X11 with Ctrl+Alt+Backspace). Then, after waiting, I can see my desktop again. Additional info: If I log out before suspending, I can log in again from GDM without waiting when I resume. So I believe it's not a problem about suspend per se. I selected gnome-screensaver as the faulty component, but this might be an issue with gnome-shell or gnome-session instead. I have a Thinkpad X121e laptop, AMD64 processor, and a 0:01.0 VGA compatible controller: ATI Technologies Inc AMD Radeon HD 6310 GraphicsATI I am using the standard open source video driver (radeon). Please tell me if you need any further information. I am not certain what is relevant (for instance, dmesg doesn't appear to show anything of value to me, but maybe I am overlooking something).
I also noticed that if I switch to a normal console, login and launch top while waiting for the screen to unlock, I see polkitd (first) and dbus-daemon (second) hogging the CPU. It might or might not be related, but something strange is going on.
I can confirm this issue with a Dell Latitude E6420, Intel all the way. Smolt profile: http://www.smolts.org/client/show/pub_32d9f27b-b51f-4bcf-9b7d-618c1f904a7f My .xsession-errors file is full of: [1320053427,000,gkbd-status.c:gkbd_status_set_current_page_for_group/] Page for group 0 is not ready They do seem to be related to the resume from suspend issue: there's a block of these every time I resume from suspend, usually around 40 to 80 of these. Sometimes, the display does not get back, no matter how long I wait (up to several minutes), and the block of messages is ~1,470 lines in size. Would gladly provide more details/debugging info if someone can tell me what/how.
I've exactly the same problem but I don't need to suspend my machine, just letting it automatically lock the screen and it needs a lot of time to get rid of the black screen and see the desktop. But I don't have those errors in .xsession-errors file.
More of the same, LENOVO Z570, Intel i915. All maintenance current as of 11/25 (kernel 3.1.2-1.fc16.i686.PAE). My frustration continues. I've tried many things not the least of which is specifying acpi=no at boot time and disabling the timeouts in the xorg.conf. Laptop functionality (screen and keyboard) goes away after a successful boot, and leaving the PC untouched for 10 minutes. My screen saver is disable. I have been able to to find a work around by either rebooting and closing the lid before the boot completes or logging in post reboot and issuing the following - gsettings set org.gnome.desktop.screensaver idle-activation-enabled false (I think this is redundant though because I've disable the screensaver) setterm -blank 0 xset -dpms The session has to remain remained logged in though and you must manually turn off the monitor (via function key) if leaving the lid open or close the lid which also turns off the monitor. I also saw this issue mentioned with the Intel graphics and a recommended fix of putting DISPLAY_QUIRK_S3_BIOS="true" in /etc/pm/config.d/config - that did not work. I'll be glad to provide any information to help solve this problem; this is just a big inconvenience which I'm sure has many laptop owners frustrated. Simply drop me an email. I remember this issue vaguely in FC14, which was eventually solve with an updated kernel. That was on my my HP G60-533CL.
Is this being looked at in any way? The Black Screen of Unresponsiveness is extremely annoying, especially since the wait time is sometimes more than several minutes. This way, it's quicker to shutdown and reboot my laptop rather than suspend/resume (I have SSD storage :-)). I'm fairly certain it's something in the Gnome stack, and all evidence points to gnome-shell. I tried (from a VTE session) to kill just about any process I have running, with no result. When I kill either gnome-session or gnome-shell, my whole graphical session is (predictably) terminated and I get the login screen again. Running "top" does not show any CPU hogging, so could it be some weird locking problem or race condition? There are 6 users on the CC list for this bug, are we really the only ones having this problem?
By the way, I should add I am seeing this also on current Debian sid + experimental repositories enabled. I have to wait only for 10 seconds or so, but it might be because the desktop machine running Debian is much faster than my laptop running Fedora.
I am also affected. When I have only one keyboard layout enabled, it does not happen. If I have two of them, it does. I wonder if it can be related to #741446
I also have four keyboard layouts enabled (italian, german, usa, usa - dvorak). Incidentally, I also have to report that this is present also in the development version of Fedora 17 as of the time of this writing.
Hi, I'm having the same issue with an HP Pavilion dm1 laptop, with this as output for lspci -v: ... 00:01.0 VGA compatible controller: ATI Technologies Inc AMD Radeon HD 6310 Graph icsATI (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 1611 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at c0000000 (32-bit, prefetchable) [size=256M] I/O ports at 3000 [size=256] Memory at d0200000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 < ?> Kernel driver in use: radeon Kernel modules: radeon ... Thanks, and best regards, HeCSa.
I am not sure which update exactly did the trick in Fedora 17, but the problem seems to have gone away in the last couple of days. I would restrict this to an update happened between Thursday and Friday (I update daily, so it means a package upload between Wednesday and Friday). Maybe wait a couple of days just to be sure before closing this bug, then it can be set as fixed in Fedora 17 (but not Fedora 16, I take?). I will attach the portion of my yum.log from Wednesday to Friday if someone wants to have a go at fixing it in f16 by backporting the right package.
Created attachment 574295 [details] My yum.log in the days that brought in the fix List of packages that might have done the trick.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Thanks for the notice. Let's see if this issue goes away when F18 will be on the road. Best regards, HeCSa.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. Thank you for reporting this bug and we are sorry it could not be fixed.