![]() Registered Member ![]()
|
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? |
![]() Administrator ![]()
|
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."
![]() Plasma FAQ maintainer - Plasma programming with Python |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
Yeah, hybrid, and I'm disabling the card with vga_switcheroo by doing the following:
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.
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! |
![]() Administrator ![]()
|
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."
![]() Plasma FAQ maintainer - Plasma programming with Python |
![]() Administrator ![]()
|
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] |
![]() Registered Member ![]()
|
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? |
![]() Administrator ![]()
|
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."
![]() Plasma FAQ maintainer - Plasma programming with Python |
![]() Registered Member ![]()
|
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! |
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot], Yahoo [Bot]