This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Screen locker delay when graphics card disabled

Tags: None
(comma "," separated)
schweickism
Registered Member
Posts
4
Karma
0
I posted this on the Fedora forum but didn't get a response, so figured I'd try here.

I'm on Fedora 18 with KDE 4.10.3.

If my computer goes to sleep with the graphics card disabled, when it wakes back up there is about a 60 - 90 second delay before I can login.

The keyboard and mouse are totally unresponsive during the delay, and sometimes the laser under the mouse is lit, sometimes not.

The locker screen is usually visible (just unresponsive) immediately, but occasionally I see an image of my desktop and sometimes the locker screen is partly transparent for the duration of the delay.

It works perfectly fine when the graphics card is enabled. And I haven't noticed any other issue when the card is disabled.

I saw a few similar bugs, but it seemed like in all the reports the screen locker didn't work at all, and in my case it's just really delayed so I wasn't sure if it's related. Any ideas?
User avatar
einar
Administrator
Posts
3402
Karma
7
OS
What do you mean exactly with "graphics card disabled"? Are you using a hybrid (integrated + discrete) solution?


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
Does your system appear to be under any other form of load, ie. hard disk activity, CPU utilisation, etc?
If there are no hardware indicators, you may need to use another system to monitor it over SSH.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
schweickism
Registered Member
Posts
4
Karma
0
einar wrote:What do you mean exactly with "graphics card disabled"? Are you using a hybrid (integrated + discrete) solution?

Yeah, hybrid, and I'm disabling the card with vga_switcheroo by doing the following:
Code: Select all
echo ON > /sys/kernel/debug/vgaswitcheroo/switch
echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
echo OFF > /sys/kernel/debug/vgaswitcheroo/switch


bcooksley wrote:Does your system appear to be under any other form of load, ie. hard disk activity, CPU utilisation, etc?
If there are no hardware indicators, you may need to use another system to monitor it over SSH.

Not that I've noticed either before it goes to sleep or after logging in, don't know about during the delay.

I just noticed this in dmesg. This is getting over my head, but having googled "drm" I'm convinced it's related.
Code: Select all
[131425.150276] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[131425.150282] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBEC (len 62, WS 0, PS 0) @ 0xCC08
[131430.145734] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[131430.145741] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBEC (len 62, WS 0, PS 0) @ 0xCC08
[131435.141200] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[131435.141216] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBEC (len 62, WS 0, PS 0) @ 0xCC08
[131440.136667] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[131440.136681] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBEC (len 62, WS 0, PS 0) @ 0xCC08

Searching for the whole message led me to this bug report.

So, if it's an issue with the kernel, will that get fixed upstream or would it be appropriate to report this with Fedora as well?

And thanks for the replies!
User avatar
einar
Administrator
Posts
3402
Karma
7
OS
If that's a kernel issue, check if the Launchpad bug report has also an upstream (kernel.org) report as well, so that when it's fixed, it will land on all distributions when they update their kernels.


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
To verify that those "drm" messages are related, try disabling compositing prior to sleeping your computer. I would also suggest ensuring your system is switched back to the boot time default (likely favouring the integrated card) prior to sleep as well.

If either of those fixes the issue - then those messages are involved.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
schweickism
Registered Member
Posts
4
Karma
0
bcooksley wrote:If either of those fixes the issue - then those messages are involved.

Yup, the drm messages and the delay go away.

Someone on the bug report I linked suggested putting a script in /etc/pm/sleep.d/ to toggle it automatically, but I've found those hooks don't get called when closing the laptop lid.

Some distributions have a lid.sh script in /etc/acpi/ that gets run when you open or close the lid. But on Fedora I only see power.sh, and it looks to me like its only purpose is to shut down if the power manager doesn't start.

Is there another way to run a script when the lid closes?
User avatar
einar
Administrator
Posts
3402
Karma
7
OS
You may want to ask in a specific Fedora communication channel, as you're likely to get much more informative answers than here (I for one don't run Fedora).


"Violence is the last refuge of the incompetent."
Image
Plasma FAQ maintainer - Plasma programming with Python
schweickism
Registered Member
Posts
4
Karma
0
In case somebody else finds this topic, here's the response I got for the lid event: http://www.forums.fedoraforum.org/showt ... ost1656403

Now I'm just running echo "ON" > /sys/kernel/debug/vgaswitcheroo/switch when the lid closes and echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch when it opens, takes care of the delay and drm warnings.

Thanks for the help!


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot], Yahoo [Bot]