Slow wake from suspend

Ask Fedora Ask in English
,
1

Ever since upgrading to Fedora 34 (from 33) I’ve noticed that the system is much slower to wake from sleep/suspend.

What happens:
When waking the computer from suspend, the screen remains black until I press a key. Sometimes I need to press a key multiple times before the gdm shows up.
I’ve also noticed that, sometimes, I am unable to reach the password prompt via keyboard and have to click anywhere to make it available.

What was expected:
Snappy response when waking from sleep and no unnecessary keystrokes/inputs

What I tried:
I tried deactivating GNOME shell extensions, but nothing changed

Any ideas?

1 Like
2

Could you take a look at the journal to see what messages are noted during the suspend/wake bit? That may give us some clues on what is holding it up:

3

Hi Ankur, thanks for your reply.
Here’s a log snippet covering the portion from the moment I put the computer in suspend mode to the moment I access the desktop again
https://gist.github.com/nilueps/5222a3249ef2f5dab9beaf9e28d4230f

Idk, but it looks like it might be a keyring problem. Which would be consistent with a recent issue I was facing: https://discussion.fedoraproject.org/t/cant-unlock-keyring-after-enabling-disabling-auto-login/72614

1 Like
4

Shell Extensions are fully deactivated btw and the problem existed before I resorted to deleting my keyring as mentioned in the linked thread

1 Like
5

I see slack.desktop making lots of network requests—I wonder if that contributes some to the delay.

There’s this too:

gnome-shell[6200]: Usage of object.actor is deprecated for AuthPrompt
                                            get@resource:///org/gnome/shell/ui/environment.js:317:29
                                            _initEntryRow@resource:///org/gnome/shell/gdm/authPrompt.js:176:9
                                            _init@resource:///org/gnome/shell/gdm/authPrompt.js:93:14
                                            _ensureAuthPrompt@resource:///org/gnome/shell/ui/unlockDialog.js:678:28
                                            _showPrompt@resource:///org/gnome/shell/ui/unlockDialog.js:717:14
                                            vfunc_key_press_event@resource:///org/gnome/shell/ui/unlockDialog.js:617:14

which may be related to the the key press not bringing up the login/password screen,
and there are a few of these that look related to the keyring issue:

goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL

Just as a test, could you create a new user and see how suspend/resume works there? That’ll help us decide if its a system level issue or a user specific one.

1 Like
6

So quitting slack had no effect.
Suspend/resume works perfectly under a new user account, however.
Any ideas for the next step?

1 Like
7

That suggests it’s something specific to the account then. I guess comparing the suspend/resume logs when using the two users would be a start? That may tell us what components are running/behaving differently?

1 Like
8

Oddly it seems the problem may have propagated to the new user as I’m encountering the same issue again: i.e screen remains black after resume, need to press a key to activate display.

Here’s the log for the new user: https://gist.github.com/nilueps/54db5895b981fe0d2640e0c919d1567e

9

There seems to be some common errors in the new user’s log only if both sessions are ‘active’. i.e. if is switch users via the top-right dialog.

new user’s log after switching from main user: https://gist.github.com/nilueps/501877b93b0ee077a10d809e9eafc763