http://bugzilla.opensuse.org/show_bug.cgi?id=977323 http://bugzilla.opensuse.org/show_bug.cgi?id=977323#c2 Stefan Vater changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |st.vater@web.de --- Comment #2 from Stefan Vater --- I have the essentially the same problem with a Dell Latitude using Tumbleweed and Kernel 4.6.2. Using the packages in the official repo, the cpu govenor is always powersave", and I cannot change to performance, which gives me pretty bad performance. However, when using cpupower from the devel:/tools repository (together with the kernel from the tumbleweed repo), it seems to work. Could you update to this version, or do you need more info? Stefan -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=977323 http://bugzilla.opensuse.org/show_bug.cgi?id=977323#c4 Elliott Scott changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elliott.scott@scottsolution | |s.us Flags|needinfo?(ernesto@csusb.edu | |) | --- Comment #4 from Elliott Scott --- I experienced the frequency scaling issue after upgrading from SLED 12 SP1 to SLED 12 SP2, going to the 4.4 kernel. I reproduced the same behavior when installing Leap 42.2 fresh install. I performed a kernel distribution upgrade to 4.9 that improved performance, but did not resolve the scaling issue. I modified the kernel parameters in the boot loader and included the parameter "acpi=noirq", and I can change frequency governors and witness CPU frequency changes. Compaq nx6125 AMD Turion64 w/PowerNow! enabled 2GB RAM 128GB SSD kernel 4.9.0-1.g8c92422-default installed My laptop sings at this point! Never experienced this kind of performance before... Used reference located at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1598312 to make suggested workaround changes. # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 36 model name : AMD Turion(tm) 64 Mobile ML-34 stepping : 2 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl eagerfpu pni lahf_lm 3dnowprefetch vmmcall bugs : fxsave_leak sysret_ss_attrs null_seg swapgs_fence bogomips : 1595.88 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc # cpupower frequency-info analyzing CPU 0: driver: powernow-k8 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 107 us hardware limits: 800 MHz - 1.80 GHz available frequency steps: 1.80 GHz, 1.60 GHz, 800 MHz available cpufreq governors: ondemand performance schedutil current policy: frequency should be within 800 MHz and 1.80 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 800 MHz (asserted by call to hardware) boost state support: Supported: no Active: no (Prior to work-around, current policy read "frequency should be within 800MHz and 800MHz". With the workaround in place, I now get the above results.) # cpupower frequency-set -g performance Setting cpu: 0 # cpupower frequency-info analyzing CPU 0: driver: powernow-k8 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 107 us hardware limits: 800 MHz - 1.80 GHz available frequency steps: 1.80 GHz, 1.60 GHz, 800 MHz available cpufreq governors: ondemand performance schedutil current policy: frequency should be within 800 MHz and 1.80 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency: 1.80 GHz (asserted by call to hardware) boost state support: Supported: no Active: no (Prior to work-around, current CPU frequency read "800MHz", even with the performance governor in effect. With the workaround in place, I now get the above results.) -- You are receiving this mail because: You are on the CC list for the bug.