Created attachment 104841 [details] Behavior before suspend When 1st boot both my core's frequencies change independently, but once i wake from suspend they are synchronized ~$ uname -r # http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc6-saucy/ 3.10.0-031000rc6-generic $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver intel_pstate intel_pstate $ cat /sys/devices/system/cpu/cpu*/cpuidle/driver/name intel_idle intel_idle $ cat /proc/cpuinfo # Only showing one core processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU B970 @ 2.30GHz stepping : 7 microcode : 0x23 cpu MHz : 1242.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm bogomips : 4589.55 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Created attachment 104851 [details] Behavior after suspend
Does this work on older kernel?
In 3.10.0rc4 it behaved like it does after suspend at 1st boot I don't believe intel_pstate was enabled for my cpu prior to 3.10 This is why I did not mark this as a regression if you are asking if this happened with the older scaling driver that used ondemand, it did not as far as I am aware
This is the script I used to get the attached charts http://pastebin.com/PYj4wwCj it uses /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq to get the current cpu frequency
Could you use turbostat to collect data on the good and bad state please. Does this happen all the time? There are a number of bugs open where both intel_pstate and ondemand are doing weird things after coming out of suspend. I the other bugs the situation would clear sometimes after a number of suspend/resume cycles. If you could see if this happens without intel_pstate it would be helpful
Strange when using acpi-cpufreq's ondemand setting cpuinfo_cur_freq is synchronized, but scaling_cur_freq is not That is under the 3.9.0 kernel ~$ turbostat turbostat_3.9.0-030900 not found You may need to install linux-tools-3.9.0-030900 there is no such package...
Please go to (kernel source)/tools/power/x86/turbostat/ run "make && make install" And then try again.
/me wonders whether an issue at my system is connected to this bug report too. I'm using the ondemand governor at a ThinkPad T420 with a i5 (4 cores, 2.6 GHz max frequency, boost at 3.1 GHz). Since kernel 3.10-rcX I've to define "intel_pstate=disable" at the kernel command line to force using the acpi driver (P-State does not know anything about niced processes ...) Now the problem: After s2ram and wakeup I notice a higher temperatur and fan noise and realized, that 3 of 4 cpu cores runs constantly at 2.6 GHz (cpu1-3, cpu0 were at the expected 800 MHz for low load) - independend from the load. I've to explicitely set the max freq to 2.4 GHz and back to 2.6 GHz. Then the current frequency was scaled accordingly to the load.
After suspend: http://pastebin.com/raw.php?i=JbZmBNrS
Before suspend: http://pastebin.com/raw.php?i=75bvfLij
Hi: Sorry for later response. Please try the following patch. I guess this will fix your issue. I found this issue also on one of my machine. --- drivers/cpufreq/cpufreq_stats.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index fb65dec..591b6fb 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -349,6 +349,7 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, switch (action) { case CPU_ONLINE: + case CPU_ONLINE_FROZEN: cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE:
Created attachment 106836 [details] debug.patch Please ignore the previous patch and try this patch. This issue is caused by timer migration during system suspend. All non-boot cpus' timer will migrate to boot cpu during system suspend. But for intel_pstate timer, it's required to executed on the per-core because the timer handler is to access the per-core msr register to get aperf and mperf and set cpufreq. After system resume, all timers are executed on the boot-cpu and only its cpufreq will be controlled and reported back to user-space.
Do I apply this patch to the latest source code on https://www.kernel.org/ ? or can I get it via http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/ If I will have to do some git cloning and stuff i will need each command i will need commands to run posted here or a link to a guide with them
Please follow these command. #git clone git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git #cd linux-pm #git checkout bleeding-edge #git apply (this patch file) #make localmodconfig #make ARCH=x86 bzImage #make modules #make modules_install #make install #reboot
The timer being added/delete for hotplug events is handled in intel_pstate_cpu_(init/exit) which are called by the cpufreq core. With this patch there would be two calls into the driver with each hotplug event.
(In reply to Dirk Brandewie from comment #15) > The timer being added/delete for hotplug events is handled in > intel_pstate_cpu_(init/exit) which are called by the cpufreq core. Hi Dirk: This situation has been changed by commit a66b2e. Currently cpufreq core will not handle hotplug events for system suspend and resume. So intel_pstate_cpu_(init/exit) will not be called and cause this issue. I will attach the formal patch which have detail description. commit a66b2e503fc79fff6632d02ef5a0ee47c1d2553d Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Date: Wed May 15 21:47:17 2013 +0200 cpufreq: Preserve sysfs files across suspend/resume The file permissions of cpufreq per-cpu sysfs files are not preserved across suspend/resume because we internally go through the CPU Hotplug path which reinitializes the file permissions on CPU online. But the user is not supposed to know that we are using CPU hotplug internally within suspend/resume (IOW, the kernel should not silently wreck the user-set file permissions across a suspend cycle). Therefore, we need to preserve the file permissions as they are across suspend/resume. The simplest way to achieve that is to just not touch the sysfs files at all - ie., just ignore the CPU hotplug notifications in the suspend/resume path (_FROZEN) in the cpufreq hotplug callback. > > With this patch there would be two calls into the driver with each hotplug > event.
Created attachment 106854 [details] formal.patch
Sorry I have not tried it yet hopefully i will find time to tomorrow I will try the new patch you posted on clean install of xubuntu 13.10 I see you signed off patch, do i still need to test/compile it? or will this show up in the intel drm nightly for Ubuntu I linked to the other day Since this is a laptop I am going to swap the HDD for my testing one and remove my SSD in my ODD slot
(In reply to pqwoerituytrueiwoq from comment #18) > Sorry I have not tried it yet hopefully i will find time to tomorrow > I will try the new patch you posted on clean install of xubuntu 13.10 > I see you signed off patch, do i still need to test/compile it? Yes, you still need test it and it hasn't been merged.
Created attachment 106867 [details] Results for newly compiled kernel Well that took all day to compile on a single core of my laptop, but i got the results Looks like it fixed it to me, also appears to have fixed a GPU issue i was having after suspend (showed up late in Linux 3.10) I Hope to see this get merged :)
Thanks for test. Rafael decided to revert commit a66b2e50 and please see following link. So this regression will not exist and the previous patch is not necessary. So mark this as resolved. http://www.spinics.net/lists/cpufreq/msg06266.html
The revert patch has been merged into Linux upstream tree. commit aae760ed21cd690fe8a6db9f3a177ad55d7e12ab Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Date: Fri Jul 12 03:45:37 2013 +0530 cpufreq: Revert commit a66b2e to fix suspend/resume regression commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown.
I can confirm it works in 3.10.3 and 3.11rc3 but in 3.10.3 I am getting the GPU corruption issue, fixed in 3.11rc3 however the permissions on this file /sys/devices/system/cpu/cpu$X/cpufreq/cpuinfo_cur_freq Where $X is greater than 0 the permissions are not preserved after suspend and are reset, i changed them on my system so I can monitor them via a applet script I made The original patch may be necessary to some extent Before Suspend: chad@A54C-NB91:~$ ls -l /sys/devices/system/cpu/cpu*/cpufreq/ /sys/devices/system/cpu/cpu0/cpufreq/: total 0 -r--r--r-- 1 root root 4096 Jul 30 06:37 affected_cpus -r--r--r-- 1 root root 4096 Jul 30 04:54 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 Jul 30 04:56 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Jul 30 06:32 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Jul 30 06:32 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Jul 30 06:37 related_cpus -r--r--r-- 1 root root 4096 Jul 30 04:55 scaling_available_governors -r--r--r-- 1 root root 4096 Jul 30 04:54 scaling_driver -rwxrwxrwx 1 root root 4096 Jul 30 06:27 scaling_governor -rw-r--r-- 1 root root 4096 Jul 30 04:54 scaling_max_freq -rw-r--r-- 1 root root 4096 Jul 30 06:37 scaling_min_freq -rwxrwxrwx 1 root root 4096 Jul 30 04:54 scaling_setspeed /sys/devices/system/cpu/cpu1/cpufreq/: total 0 -r--r--r-- 1 root root 4096 Jul 30 06:37 affected_cpus -r--r--r-- 1 root root 4096 Jul 30 06:27 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 Jul 30 06:37 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Jul 30 06:37 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Jul 30 06:37 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Jul 30 06:37 related_cpus -r--r--r-- 1 root root 4096 Jul 30 06:37 scaling_available_governors -r--r--r-- 1 root root 4096 Jul 30 06:27 scaling_driver -rwxrwxrwx 1 root root 4096 Jul 30 06:27 scaling_governor -rw-r--r-- 1 root root 4096 Jul 30 06:27 scaling_max_freq -rw-r--r-- 1 root root 4096 Jul 30 06:37 scaling_min_freq -rwxrwxrwx 1 root root 4096 Jul 30 06:27 scaling_setspeed After Suspend: chad@A54C-NB91:~$ ls -l /sys/devices/system/cpu/cpu*/cpufreq/ /sys/devices/system/cpu/cpu0/cpufreq/: total 0 -r--r--r-- 1 root root 4096 Jul 30 06:37 affected_cpus -r--r--r-- 1 root root 4096 Jul 30 04:54 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 Jul 30 04:56 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Jul 30 06:32 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Jul 30 06:32 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Jul 30 06:37 related_cpus -r--r--r-- 1 root root 4096 Jul 30 04:55 scaling_available_governors -r--r--r-- 1 root root 4096 Jul 30 04:54 scaling_driver -rwxrwxrwx 1 root root 4096 Jul 30 06:38 scaling_governor -rw-r--r-- 1 root root 4096 Jul 30 04:54 scaling_max_freq -rw-r--r-- 1 root root 4096 Jul 30 06:37 scaling_min_freq -rwxrwxrwx 1 root root 4096 Jul 30 04:54 scaling_setspeed /sys/devices/system/cpu/cpu1/cpufreq/: total 0 -r--r--r-- 1 root root 4096 Jul 30 06:38 affected_cpus -r-------- 1 root root 4096 Jul 30 06:38 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 Jul 30 06:38 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Jul 30 06:38 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Jul 30 06:38 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Jul 30 06:38 related_cpus -r--r--r-- 1 root root 4096 Jul 30 06:38 scaling_available_governors -r--r--r-- 1 root root 4096 Jul 30 06:38 scaling_driver -rw-r--r-- 1 root root 4096 Jul 30 06:38 scaling_governor -rw-r--r-- 1 root root 4096 Jul 30 06:38 scaling_max_freq -rw-r--r-- 1 root root 4096 Jul 30 06:38 scaling_min_freq -rw-r--r-- 1 root root 4096 Jul 30 06:38 scaling_setspeed
This issue will be resolved by the following patchset which has been merged into linux-pm tree. https://lkml.org/lkml/2013/7/29/692
Still having the permission issue with 3.11-rc5 should i assume it has not been merged?
Permissions are preserved in 3.12rc2, never tried rc1