Bug 185591 - Computer is extremely slow after coming back from suspend to ram
Summary: Computer is extremely slow after coming back from suspend to ram
Status: RESOLVED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2009-02-26 11:18 UTC by Marc de Bruijn
Modified: 2018-09-19 14:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc de Bruijn 2009-02-26 11:18:02 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Debian testing/unstable Packages

I'm certain I didn't have this problem when running GNOME and the same kernel version I'm running now (2.6.26-1-686). But when I close my laptop lid (I've configured PowerDevil to suspend to RAM), or invoke "Suspend to RAM" from the menu and hit a button to get the machine back from sleep my whole desktop environment is extremely slow. Window and mouse rendering are very slow and choppy and the system becomes so slow it's unusable. Xorg seems to be using the most memory, but the normal amount of CPU according to System Activity.

There is no consistent method to reproduce this, it doesn't happen every time, but only after one or two suspends. Most of the time the first suspend after a reboot is fine, the second as well most of the time, but the third is generally the killing blow. Logging out and in resolves this issue as soon as KDM is displayed, so the problem involves only the running KDE session.

I'm not sure if there are any relevant logs or kernel messages regarding this issue, if there are I can provide them the next time my system decides to become slow. I have compositing enabled, so I might try if this issue is reproducible with compositing disabled.
Comment 1 Marc de Bruijn 2009-02-26 11:21:13 UTC
Running Xorg 1.7.3+18 (Debian testing) by the way.
Comment 2 Martin Flöser 2009-12-15 10:13:20 UTC
It's not a kwin bug and I don't know if this is a KDE bug at all. Perhaps bug squad members have an idea.
Comment 3 Thomas Lübking 2009-12-15 16:44:55 UTC
@Marc:
- Is the problem still present anyway?
> Window and mouse rendering are very slow
                     ^^^^^^^^^^^^^^^^
- Do you use the SW or HW cursor?
- Do you use the Desktop FX?
- Does switching them off (in case) help?
- What's your GPU?

> Xorg seems to be using the most memory
- What do you mean by "most" (i.e. an absolute value would be good), do you think X leaks? (during the suspense, i.e. was the amount of RAM used by X significantly lower before the suspense)

- When the system is slow after the suspension, how much VRAM does X consume (use "xrestop" to check)
Comment 4 Marc de Bruijn 2009-12-16 01:00:20 UTC
I'm afraid I'm not using that particular machine as a production machine with KDE on it anymore. So, sadly, I can't verify most of the information you ask.

The GPU for that machine was a ATI Mobility Radeon X1600. As for the memory usage of X, it spiked after the suspension. In retrospect, it could very well be an issue with Xorg and not with KDE.

It's probably better to close this bug report as no other reports have been committed regarding this issue since the original posting date. Thanks for looking into it regardless though!
Comment 5 Chao Feng 2015-04-06 10:16:07 UTC
More info is needed to further check. And this issue is too old. If it still happen, please open a new one.
Comment 6 Andrew Crouthamel 2018-09-19 14:32:00 UTC
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.