Bug 745710 - On resume from suspend, long waiting time to get my desktop back after unlocking
On resume from suspend, long waiting time to get my desktop back after unlocking
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-10-13 03:29 EDT by Matteo Settenvini
Modified: 2013-02-13 16:46 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-13 16:46:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My yum.log in the days that brought in the fix (22.43 KB, text/plain)
2012-04-01 04:47 EDT, Matteo Settenvini
no flags Details

  None (edit)
Description Matteo Settenvini 2011-10-13 03:29:24 EDT
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):


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).
Comment 1 Matteo Settenvini 2011-10-15 15:12:29 EDT
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.
Comment 2 Steven Bakker 2011-10-31 11:31:44 EDT
I can confirm this issue with a Dell Latitude E6420, Intel all the way.

Smolt profile:


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.
Comment 3 lefred 2011-11-10 04:37:39 EST
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.
Comment 4 Don Fore 2011-11-25 22:33:47 EST
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.
Comment 5 Steven Bakker 2012-01-20 03:30:36 EST
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?
Comment 6 Matteo Settenvini 2012-01-20 04:09:37 EST
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.
Comment 7 Štefan Gurský 2012-02-11 18:30:13 EST
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
Comment 8 Matteo Settenvini 2012-02-11 18:36:14 EST
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.
Comment 9 HeCSa 2012-03-02 19:18:41 EST

   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,

Comment 10 Matteo Settenvini 2012-04-01 04:42:43 EDT
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.
Comment 11 Matteo Settenvini 2012-04-01 04:47:23 EDT
Created attachment 574295 [details]
My yum.log in the days that brought in the fix

List of packages that might have done the trick.
Comment 12 Fedora End Of Life 2013-01-16 12:16:20 EST
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: 
Comment 13 HeCSa 2013-01-16 13:29:10 EST
Thanks for the notice.
Let's see if this issue goes away when F18 will be on the road.
Best regards,

Comment 14 Fedora End Of Life 2013-02-13 16:46:33 EST
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.

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