You are not logged in.
Hello,
I'm running kdebase-workspace as my DE. For the past week or so, I've noticed that my system seems to be substantially more sluggish, and it seems to be correlated to using the laptop after resuming from suspend. I cannot directly quantify it, really, but there is a significant difference (i.e. switching tabs in chrome goes from instantaneous to taking up to 1s or more). This seems to persist until a reboot, at which point the system is back to performing quickly, as expected.
As to what is eating up performance, I have not noticed anything in particular when inspecting via htop. Typically "kdeinit4: plasma-desktop" or Chrome (if it's open) are the top offenders, but they do not seem to be using any more cpu than they usually do, yet the sluggishness remains. I originally noticed this problem while running on KF5+Plasma, and then downgraded to KDE4 in hopes it would go away. It did not, so then I tried clearing out my ~/.kde* folders and the kde-related items in ~/.config and ~/.cache. Using a "bare" KDE4 setup, this problem is still occurring, and I've run out of ideas on how to troubleshoot it any further.
Does anyone have any idea what is going on? Or how to further troubleshoot the problem and nail down what's actually causing the system to get so sluggish?
Thanks in advance.
Last edited by jat255 (2015-07-18 22:09:59)
Offline
i have the exact same problem. after resume my system is much much slower. all the running processes seem to be using a lot more cpu than before the suspend. and my cpu freq runs higher.
it seems to be kernel related as i've tried it with gnome/openbox/i3 and even fresh installs and it still happens.
however, if i downgrade my kernel to anything < 4 the issue goes away.
i was hoping 4.1 would fix it but i can't find any solutions or even any other people with this problem.
Offline
Well I'm glad to hear I'm not the only one. I hadn't seen anything about it in all of my searches. I'm not on my machine now, but maybe dmesg or something might show some useful output? I hadn't checked because I assumed it was KDE-related.
Offline
here is my dmesg after resume.
nothing jumps out at me
[ 861.844704] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
[ 861.864089] wlp2s0: deauthenticating from 00:1a:70:ea:07:c5 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 861.891863] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
[ 861.926862] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[ 867.142688] PM: Syncing filesystems ... done.
[ 867.804198] PM: Preparing system for mem sleep
[ 867.804471] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 867.806731] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 867.808048] PM: Entering mem sleep
[ 867.808085] Suspending console(s) (use no_console_suspend to debug)
[ 867.809416] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 867.840620] sd 0:0:0:0: [sda] Stopping disk
[ 868.508364] PM: suspend of devices complete after 700.386 msecs
[ 868.521731] PM: late suspend of devices complete after 13.352 msecs
[ 868.522723] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[ 868.535119] PM: noirq suspend of devices complete after 13.387 msecs
[ 868.535475] ACPI: Preparing to enter system sleep state S3
[ 868.537054] PM: Saving platform NVS memory
[ 868.537105] Disabling non-boot CPUs ...
[ 868.537166] intel_pstate CPU 1 exiting
[ 868.538609] smpboot: CPU 1 is now offline
[ 868.540496] ACPI: Low-level resume complete
[ 868.540545] PM: Restoring platform NVS memory
[ 868.540928] Enabling non-boot CPUs ...
[ 868.540963] x86: Booting SMP configuration:
[ 868.540964] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 868.554314] cache: parent cpu1 should not be sleeping
[ 868.554456] CPU1 is up
[ 868.555555] ACPI: Waking up from system sleep state S3
[ 868.557759] acpi LNXPOWER:00: Turning OFF
[ 868.569912] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 868.570133] PM: noirq resume of devices complete after 12.361 msecs
[ 868.570320] PM: early resume of devices complete after 0.164 msecs
[ 868.573086] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 868.573125] rtlwifi: rtlwifi: wireless switch is on
[ 868.586516] sd 0:0:0:0: [sda] Starting disk
[ 868.796396] usb 1-1.1: reset high-speed USB device number 3 using ehci-pci
[ 868.881502] PM: resume of devices complete after 311.334 msecs
[ 868.881843] PM: Finishing wakeup.
[ 868.881847] Restarting tasks ... done.
[ 868.909488] ata5: SATA link down (SStatus 0 SControl 300)
[ 868.919462] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 868.919493] ata4: SATA link down (SStatus 0 SControl 300)
[ 868.929410] ata6.00: configured for UDMA/100
[ 869.105115] psmouse serio1: synaptics: queried max coordinates: x [..5692], y [..4680]
[ 870.375805] wlp2s0: authenticate with 00:1a:70:ea:07:c5
[ 870.392381] wlp2s0: send auth to 00:1a:70:ea:07:c5 (try 1/3)
[ 870.394131] wlp2s0: authenticated
[ 870.394273] rtl8192ce 0000:02:00.0 wlp2s0: disabling HT as WMM/QoS is not supported by the AP
[ 870.394276] rtl8192ce 0000:02:00.0 wlp2s0: disabling VHT as WMM/QoS is not supported by the AP
[ 870.395988] wlp2s0: associate with 00:1a:70:ea:07:c5 (try 1/3)
[ 870.399084] wlp2s0: RX AssocResp from 00:1a:70:ea:07:c5 (capab=0x411 status=0 aid=1)
[ 870.399655] wlp2s0: associated
[ 871.158287] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 871.160241] ata1.00: configured for UDMA/100Offline
Hmm, me neither, but I'm certainly not an expert. My intuition says it might be something CPU scheduler related? It feels like the same sort of general decrease in performance that you'd get on "powersave" or something, but cpuinfo told me I was on "performance" both before and after resume, so maybe not.
Offline
but cpuinfo told me I was on "performance" both before and after resume, so maybe not.
i stay on powersave but i tried switching from one to the other after a resume and nothing changed.
my laptop is a toshiba satellite with intel graphics. may i ask what your laptop/graphics are?
Offline
may i ask what your laptop/graphics are?
Yeah, I've got a Dell Latitude E7240 with intel graphics as well.
Offline
Bumping in case anyone else is experiencing this. artjermyn, are you still seeing this? Mine hasn't improved at all, and now I just shut my computer down instead of suspending it, which is quite an annoyance.
Offline
Just wanted to post that I found this thread:
https://bbs.archlinux.org/viewtopic.php?id=138250
The solution for this user (back in 2012!) was to do a full power cycle. i.e. boot the laptop with no battery, shut it down, replace the battery, and boot up again. I did this procedure (holding the power button down for about 30 seconds with the battery out and AC adapter disconnected, just to be safe), and sure enough, it seems as though the system is speedy like I remember, even after suspend. Perhaps this might work for you, artjermyn?
I'm going to give this a few days of testing before marking as solved.
Offline
Thanks for the info but no dice. I tried your solution and my system is still horribly slow after resume. I'm glad it worked for you.
Im currently using the lts kernel and its working OK. Maybe by the time it reaches end of life they'll have fixed the problem.
from looking around there does seem to be a lot of people having problems with suspend/hibernate/power with 4.x, but the bugs are all different. Something in 4 borked it and I'm hoping 4.2 fixes it.
Offline
I've had similar issues on my Dell Latitude E6420 with Intel Sandy Bridge graphics. The CPU frequency multiplier got stuck at the lowest value after resume. I currently work around the issue by switching back to the old acpi-cpufreq frequency scaling driver. Add "intel_pstate=disable" to your kernel command line to try it.
Offline
I also face the same problem but not always.
What i got is that all the apps are swapped out during suspend and are brought back on demand.
Whenever i feel that my system is slow, I check my free memory by using this command:
free -mit will produce output like this:
total used free shared buff/cache available
Mem: 3756 1008 1706 114 1042 2580
Swap: 9535 0 9535As you can see my swap is empty. Yours may be using even though the ram has space.
What i do to bring all my programs back to main memory from secondary memory is to turn swap off and then on again.
BUT BEWARE: IF YOUR MAIN MEMORY DOESN'T HAVE ENOUGH SPACE TO COPY ALL THE PROGRAMS FROM SWAP, IT MAY HAVE UNEXPECTED BEHAVIOUR.
to turn swap off :
sudo swapoff -ato turn swap back on :
sudo swapon -aBUT DO THIS ONLY IF YOU ARE SURE THAT YOUR RAM HAS ENOUGH SPACE LEFT TO COPY BACK ALL THE PROGRAMS FROM SECONDARY MEMORY.
You can see the free space in main memory from the command posted above ( free -m)
Hope this helps.
Offline
Just wanted to post that I found this thread:
https://bbs.archlinux.org/viewtopic.php?id=138250The solution for this user (back in 2012!) was to do a full power cycle. i.e. boot the laptop with no battery, shut it down, replace the battery, and boot up again. I did this procedure (holding the power button down for about 30 seconds with the battery out and AC adapter disconnected, just to be safe), and sure enough, it seems as though the system is speedy like I remember, even after suspend. Perhaps this might work for you, artjermyn?
I'm going to give this a few days of testing before marking as solved.
Sure enough, it seems like it was slow again today, so definitely not a solution...
I'll try what deathholes suggested next and see if that solves it.
Offline
to turn swap off :
sudo swapoff -ato turn swap back on :
sudo swapon -aHope this helps.
Thanks for the suggestion. Unfortunately, it doesn't seem like this is a swap issue on my machine, as the sluggishness persists even after flushing out the swap.
Offline
Still on the intel_pstate driver, I noticed something interesting after a resume. Here is the ouput of cpupower:
○ sudo cpupower frequency-info ▸▸▸▸▸▸▸▸▹▹
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 2.90 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 1.45 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 371 MHz (asserted by call to hardware).
boost state support:
Supported: yes
Active: yesWhat sticks out to me is that the "current CPU freq" is 371MHz, even though the minimum is specified as 800MHz. Perhaps this is something that's causing the sluggishness?
EDIT: Sure enough, after a restart, (even on powersave) the cpu freq stays around 1.7GHz during normal use, and the system is responsive. Then after a suspend and resume, it's pegged down at 370MHz again and the system is sluggish. I'm definitely convinced now that this is a bug in the intel_pstate driver...
Last edited by jat255 (2015-07-31 03:27:21)
Offline
What sticks out to me is that the "current CPU freq" is 371MHz and the minimum is specified as 800MHz
My problem seems to be the exact opposite. My cpu freq runs much much higher after i resume.
Seems to be many different problems with resume in 4.x.
Offline
Here's a kernel bug report that's probably related. Some people report too high CPU frequencies after resume, some the opposite. For me (and others apparently) the trouble started way before 4.0
Offline
Same problem on Dell Latitude 6430u. After resume from suspend, the computer "may" becomes slower. Thought it is caused by Xfce4, but tried on LXDE also the same. The slowness is not always same. No high CPU usage. Restart or hibernate/resume, then the speed is coming back.
Offline
I have the exact same problem (for quite a long time now), and i noticed it on multiple linux distributions with 'recent' kernels: fedora 21, opensuse 13.2, ubuntu 14.04. This is also independent of the window manager used (kde4, gnome3, unity, dwm, twm).
My guess is that it's a kernel/intel bug, introduces somewhere after 3.2 (debian wheezy uses 3.2 and that kernel does not show this problem on my hardware).
I also own a dell 5420 with intel graphics, so maybe it's sandy bridge related?
This bug is annoying the hell out of me, i simply cannot work after a resume, so a full restart is necessary ALL THE TIME 8(
Last edited by drm00 (2015-08-11 19:57:06)
Offline
What sticks out to me is that the "current CPU freq" is 371MHz, even though the minimum is specified as 800MHz. Perhaps this is something that's causing the sluggishness?
For users that suffer from this issue, I suspect I know what the problem is, but not why it occurs. I am searching for confirmation or denial.
When you experience the stuck low CPU frequency condition after resume from suspend, could you please do the following and report back (steps 1 and 2 are needed before any suspend):
1.) (needed once per boot) sudo modprobe msr
2.) before any suspend: sudo rdmsr -a 0x19a
3.) after a suspend that results in the stuck low CPU frequencies:
sudo rdmsr -a 0x19a
4.) If the result from step 3 is not 0, then:
sudo wrmsr -a 0x19a 0x0
and check it:
sudo rdmsr -a 0x19a
5.) Are the CPU frequencies O.K. now?
Note: I do not actually use the Arch distribution, so I don't know if you have rdmsr and wrmsr by default or if you have to install some additional package.
Last edited by Doug Smythies (2015-09-03 01:21:26)
Offline
For users that suffer from this issue, I suspect I know what the problem is, but not why it occurs. I am searching for confirmation or denial.
When you experience the stuck low CPU frequency condition after resume from suspend, could you please do the following and report back (steps 1 and 2 are needed before any suspend):
1.) (needed once per boot) sudo modprobe msr
2.) before any suspend: sudo rdmsr -a 0x19a
3.) after a suspend that results in the stuck low CPU frequencies:
sudo rdmsr -a 0x19a
4.) If the result from step 3 is not 0, then:
sudo wrmsr -a 0x19a 0x0
and check it:
sudo rdmsr -a 0x19a
5.) Are the CPU frequencies O.K. now?Note: I do not actually use the Arch distribution, so I don't know if you have rdmsr and wrmsr by default or if you have to install some additional package.
Doug, thank you so much for your feedback. I think you might be on to something here...
For those wanting to try this out, since there's no msr package for Arch, you'll need to download and compile the msr-tools yourself from here.
From what I understand (which is not much), the 0x19a register controls the software clock modulation on the processor, correct? Before suspend, this is:
$ sudo ./rdmsr 0x19a
0After a suspend/resume with locked CPU freqs, this changes to:
$ sudo ./rdmsr -x 0x19a # hex output
17
$ sudo ./rdmsr -d 0x19a # decimal output
23I can write the register back to zero, and confirm that it works, but unfortunately it does not free up the frequencies...
$ sudo ./wrmsr 0x19a 0x0
$ sudo ./rdmsr -x 0x19a
0If it is any clue, I did notice that I can suspend/resume all I want while plugged into AC power, and I do not see the CPU freqs locking up. It only occurs if I suspend/resume while on battery power. For testing, here is a sequence of suspend/resume cycles that I did, and what the results were:
Suspend - AC; Resume - Batt -> no lock
Suspend - Batt; Resume - Batt -> lock
Suspend - AC; Resume - AC -> no lock (even if CPU locked when going to sleep)
Suspend - AC; Resume - Batt -> no lock
Suspend - Batt; Resume - AC -> no lock (even if CPU locked when going to sleep)So it would appear that only suspending and resuming while on battery causes this strange problem. In fact, a workaround might be to do another suspend/resume cycle with the laptop plugged in, or only suspending while on AC (if you want to resume while on battery). Does any of this make sense as to where a fix could be found?
FYI, I did not have a "-a" option on my build of rdmsr, but hopefully these were the right values to report. Here is the help text from my copy of the program:
$ sudo ./rdmsr -h
Usage: ./rdmsr [options] regno
--help -h Print this help
--version -V Print current version
--hexadecimal -x Hexadecimal output (lower case)
--capital-hex -X Hexadecimal output (upper case)
--decimal -d Signed decimal output
--unsigned -u Unsigned decimal output
--octal -o Octal output
--c-language -c Format output as a C language constant
--zero-pad -0 Output leading zeroes
--raw -r Raw binary output
--processor # -p Select processor number (default 0)
--bitfield h:l -f Output bits [h:l] only
$ sudo ./rdmsr -V
./rdmsr: version msr-tools-1.1.2Offline
jat255: Thank you so much for your quick reply. I have been asking for this information on forums and bug reports for sometime now, and you are the first reply. By the way, I have heard about the battery verses AC thing from other sources also. And yes, Clock Modulation seems to be involved. Is your computer a Dell? [EDIT: Oh, I see: "Dell Latitude E7240 with intel graphics"] The general consensus is that the root issue is a BIOS issue, however I have never seen proof and I also suspect an uninitialized register after resume.
It is a problem that the version of msr-tools you compiled does not have the -a option, which means all processors. I suspect Clock Modulation maybe never got disabled in your case, but am not sure.
I am using version 1.3. You have the -p option, so could you clear each processor, and see if the CPU frequencies go back to normal?
Last edited by Doug Smythies (2015-09-03 03:32:26)
Offline
Then after a suspend and resume, it's pegged down at 370MHz again and the system is sluggish. I'm definitely convinced now that this is a bug in the intel_pstate driver...
By the way, the issue merely manifests itself in a much much more apparent way with the current version of the intel_pstate driver. The acpi-cpufreq and intel_pstate frequency scaling drivers respond entirely differently to Clock Modulation.
Offline
It is a problem that the version of msr-tools you compiled does not have the -a option, which means all processors. I suspect Clock Modulation maybe never got disabled in your case, but am not sure.
I am using version 1.3. You have the -p option, so could you clear each processor, and see if the CPU frequencies go back to normal?
I see this now. With a better search, I found the source for v1.3 of msr-tools. I went ahead and made an AUR arch package for it that is available here
I can happily confirm that when the cpu is locked down to the lower frequencies, running
$ sudo wrmsr -a 0x19a 0x0 indeed unlocks the CPU! Needless to say, I cannot thank you enough for proposing this solution, as this has been a problem aggravating me for quite some time.
Barring a BIOS-level fix, I suppose the best thing to do would be to write some sort of resume hook that zeros out the 0x19a register during the resume process.
Offline
And.... fixed!
The following setup allowed me to run the commands upon resume from suspend, and I can confirm that after a suspend/resume cycle on battery, the CPU frequencies are no longer locked down. My laptop is usable again!
This method will depend on an installation of rdmsr/wrmsr (version 1.3) available somewhere on the path. If you are using Arch, feel free to use the following AUR package to get these commands.
Save the following as a script somewhere (I used ~/bin/zero_clock_mod_msr), and make it executable (chmod 755 ~/bin/zero_clock_mod_msr) (note, the echo commands are not necessary, but are useful to confirm the script is doing what you want):
#!/bin/bash
logfile="$HOME/zero.log"
#echo "$(date)" >> $logfile
#echo "before writing" >> $logfile
#rdmsr -a 0x19a >> $logfile
wrmsr -a 0x19a 0x0
#echo "after writing" >> $logfile
#rdmsr -a 0x19a >> $logfile
#echo "" >> $logfileNow write a systemd unit file and place it in /etc/systemd/system/. I saved the following as /etc/systemd/system/clock_mod-fix.service:
[Unit]
Description=Flushes the cpu clock modulation MSR to relase cpu lock caused by BIOS bug
After=suspend.target
[Service]
User=root
Type=oneshot
ExecStart=/home/josh/bin/zero_clock_mod_msr
TimeoutSec=0
StandardOutput=syslog
[Install]
WantedBy=suspend.targetEnable the unit by running:
$ sudo systemctl enable clock_mod-fix.service By telling it to run after a suspend, it will run whatever script you put in the ExecStart line upon resume from sleep. If you have the logging functions un-commented in the script, you'll see that the MSR values are all zeroed out upon resume, and the system should be snappy and responsive.
EDIT: Doug, do you know if there is a bug report somewhere that has anybody working on this? I would be happy to contribute the following code there or help debug so we can get a real fix, rather than this hack-ish workaround.
Last edited by jat255 (2015-09-03 15:19:33)
Offline