[Bug 859809] New: very bad performance on Pentium(R) CPU B950 (regression)
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c0 Summary: very bad performance on Pentium(R) CPU B950 (regression) Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: jnelson-suse@jamponi.net QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Previously, this laptop (a lenovo B570) had openSUSE 12.3 and it performed just fine (with the 'ondemand' governor). Upgraded to 13.1, and it is very slow. Almost always stuck at 800MHz, and *almost* unusable. The transition latency value might have something to do with it, but note that 'ondemand' is no longer available for some reason. Setting to 'performance' works (until the next boot). linux-k1fq:/sys/devices/system/cpu/cpu0/cpufreq # for i in *; do echo -n "$i - "; cat $i; done affected_cpus - 0 cpuinfo_cur_freq - 882000 cpuinfo_max_freq - 2100000 cpuinfo_min_freq - 800000 cpuinfo_transition_latency - 4294967295 related_cpus - 0 scaling_available_governors - performance powersave scaling_driver - intel_pstate scaling_governor - powersave scaling_max_freq - 2100000 scaling_min_freq - 800000 scaling_setspeed - <unsupported> linux-k1fq:/sys/devices/system/cpu/cpu0/cpufreq # Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c1 Borislav Petkov <bpetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bpetkov@suse.com, | |trenn@suse.com --- Comment #1 from Borislav Petkov <bpetkov@suse.com> 2014-01-22 10:08:25 UTC --- Thomas, where did the ondemand governor go? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c Borislav Petkov <bpetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |trenn@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c2 Thomas Renninger <trenn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|trenn@suse.com | AssignedTo|kernel-maintainers@forge.pr |trenn@suse.com |ovo.novell.com | --- Comment #2 from Thomas Renninger <trenn@suse.com> 2014-01-22 12:07:27 UTC ---
scaling_driver - intel_pstate intel_pstate driver does not use ondemand governor, but scales up and down itself. I also realized that rather late...
Please make use of the cpupower package to evaluate cpufreq stuff. cpupower frequency-info
cpuinfo_transition_latency - 4294967295 This is wrong, not sure whether it is used in intel_pstate driver, this is: 0xffffffff
cpupower monitor -m Mperf shows the real frequency used over a period of time. cat /dev/zero >/dev/null will utilize one CPU core with 100% -> freq must be set to highest immediately cpupower frequency-set -g performance -> does performance governor make a difference? Please play a bit with the stuff and report back. Also attach: cat /proc/cpuinfo output, so that we know the exact CPU used. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c3 --- Comment #3 from Jon Nelson <jnelson-suse@jamponi.net> 2014-01-22 15:04:36 UTC --- Idle: linux-k1fq:~ # cpupower monitor -m Mperf |Mperf CPU | C0 | Cx | Freq 0| 6.67| 93.33| 894 1| 6.51| 93.49| 894 linux-k1fq:~ # Executing /dev/zero > /dev/null in the background: linux-k1fq:~ # cat /dev/zero > /dev/null & [1] 6179 linux-k1fq:~ # cpupower monitor -m Mperf |Mperf CPU | C0 | Cx | Freq 0| 13.82| 86.18| 897 1|100.00| 0.00| 897 Notice C0 is at 100%, but frequency hasn't changed. and /proc/cpuinfo linux-k1fq:~ # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU B950 @ 2.10GHz stepping : 7 microcode : 0x29 cpu MHz : 1302.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 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 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 : 4190.50 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU B950 @ 2.10GHz stepping : 7 microcode : 0x29 cpu MHz : 1848.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 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 : 4190.50 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: linux-k1fq:~ # Setting to performance: linux-k1fq:~ # cpupower frequency-set -g performance Setting cpu: 0 Setting cpu: 1 Idle: linux-k1fq:~ # cpupower monitor -m Mperf |Mperf CPU | C0 | Cx | Freq 0| 14.98| 85.02| 2004 1| 15.09| 84.91| 2031 While cat'ing, again: linux-k1fq:~ # cat /dev/zero > /dev/null & [1] 6218 linux-k1fq:~ # cpupower monitor -m Mperf |Mperf CPU | C0 | Cx | Freq 0|100.00| 0.00| 2094 1| 8.59| 91.41| 2094 linux-k1fq:~ # -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c4 Thomas Renninger <trenn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lin.x.wang@intel.com, | |marc.ruehrschneck@suse.com --- Comment #4 from Thomas Renninger <trenn@suse.com> 2014-01-23 13:43:40 UTC --- Adding Intel, I do not have time for this now, due to other SLE12 issues. Be aware that this bug probably affects SLE12 as well. Unfortunately the author of the driver: dirk.j.brandewie@intel.com Does not have a bugzilla account. I am rather sure I saw intel_pstate driver working, maybe the problem is that intel_pstate thinks the cores can be switching frequencies independently, but they cannot (just a guess)? Anyway, it would be great if Intel can look closer at this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c5 --- Comment #5 from Dirk Brandewie <dirk.j.brandewie@intel.com> 2014-01-23 19:46:48 UTC --- can you run: cat /dev/zero > /dev/null & perf record -a 1 -c 1 -e power:pstate_sample sleep 5 with this patch applied to your kernel? commit 0049f3563ded94b560c8471b4abc17a8b985a180 Author: Dirk Brandewie <dirk.j.brandewie@intel.com> Date: Thu Jan 23 11:21:43 2014 -0800 intel_pstate: Add trace point to report internal state. Add perf trace event "power:pstate_sample" to report driver state to aid in diagnosing issues reported against intel_pstate. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> --- drivers/cpufreq/intel_pstate.c | 25 ++++++++++++++++++++ include/trace/events/power.h | 53 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index e8c3db8..2b69a4d 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -47,6 +47,8 @@ static inline int32_t div_fp(int32_t x, int32_t y) return div_s64((int64_t)x << FRAC_BITS, (int64_t)y); } +static u64 energy_divisor; + struct sample { int core_pct_busy; u64 aperf; @@ -444,6 +446,7 @@ static inline void intel_pstate_sample(struct cpudata *cpu) rdmsrl(MSR_IA32_APERF, aperf); rdmsrl(MSR_IA32_MPERF, mperf); + cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT; cpu->samples[cpu->sample_ptr].aperf = aperf; cpu->samples[cpu->sample_ptr].mperf = mperf; @@ -491,6 +494,7 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) ctl = pid_calc(pid, busy_scaled); steps = abs(ctl); + if (ctl < 0) intel_pstate_pstate_increase(cpu, steps); else @@ -500,10 +504,17 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) static void intel_pstate_timer_func(unsigned long __data) { struct cpudata *cpu = (struct cpudata *) __data; + struct sample *sample; + u64 energy; intel_pstate_sample(cpu); + + sample = &cpu->samples[cpu->sample_ptr]; + rdmsrl(MSR_PKG_ENERGY_STATUS, energy); + intel_pstate_adjust_busy_pstate(cpu); + if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) { cpu->min_pstate_count++; if (!(cpu->min_pstate_count % 5)) { @@ -512,6 +523,15 @@ static void intel_pstate_timer_func(unsigned long __data) } else cpu->min_pstate_count = 0; + trace_pstate_sample(fp_toint(sample->core_pct_busy), + fp_toint(intel_pstate_get_scaled_busy(cpu)), + cpu->pstate.current_pstate, + sample->mperf, + sample->aperf, + div64_u64(energy,energy_divisor), + sample->freq); + + intel_pstate_set_sample_time(cpu); } @@ -696,6 +716,7 @@ static int __init intel_pstate_init(void) { int cpu, rc = 0; const struct x86_cpu_id *id; + u64 units; if (no_load) return -ENODEV; @@ -717,8 +738,12 @@ static int __init intel_pstate_init(void) if (rc) goto out; + rdmsrl(MSR_RAPL_POWER_UNIT, units); + energy_divisor = 1 << ((units >> 8) & 0x1f); /* bits{12:8} */ + intel_pstate_debug_expose_params(); intel_pstate_sysfs_expose_params(); + return rc; out: get_online_cpus(); diff --git a/include/trace/events/power.h b/include/trace/events/power.h index 8e42410..735eb59 100644 --- a/include/trace/events/power.h +++ b/include/trace/events/power.h @@ -35,6 +35,59 @@ DEFINE_EVENT(cpu, cpu_idle, TP_ARGS(state, cpu_id) ); +TRACE_EVENT(pstate_sample, + + TP_PROTO(u32 core_busy, + u32 scaled_busy, + u32 state, + u64 mperf, + u64 aperf, + u32 energy, + u32 freq + ), + + TP_ARGS(core_busy, + scaled_busy, + state, + mperf, + aperf, + energy, + freq + ), + + TP_STRUCT__entry( + __field(u32, core_busy) + __field(u32, scaled_busy) + __field(u32, state) + __field(u64, mperf) + __field(u64, aperf) + __field(u32, energy) + __field(u32, freq) + + ), + + TP_fast_assign( + __entry->core_busy = core_busy; + __entry->scaled_busy = scaled_busy; + __entry->state = state; + __entry->mperf = mperf; + __entry->aperf = aperf; + __entry->energy = energy; + __entry->freq = freq; + ), + + TP_printk("core_busy=%lu scaled=%lu state=%lu mperf=%llu aperf=%llu energy=%lu freq=%lu ", + (unsigned long)__entry->core_busy, + (unsigned long)__entry->scaled_busy, + (unsigned long)__entry->state, + (unsigned long long)__entry->mperf, + (unsigned long long)__entry->aperf, + (unsigned long)__entry->energy, + (unsigned long)__entry->freq + ) + +); + /* This file can get included multiple times, TRACE_HEADER_MULTI_READ at top */ #ifndef _PWR_EVENT_AVOID_DOUBLE_DEFINING #define _PWR_EVENT_AVOID_DOUBLE_DEFINING -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c6 --- Comment #6 from Dirk Brandewie <dirk.j.brandewie@intel.com> 2014-01-23 21:17:43 UTC --- Sorry wrong version of the patch for 3.11.y here is the correct patch. can you run: cat /dev/zero > /dev/null & perf record -a -c 1 -e power:pstate_sample sleep 5 commit d2564114f8ea324f3e6cc52901c650e95e3f7192 Author: Dirk Brandewie <dirk.j.brandewie@intel.com> Date: Thu Jan 23 11:21:43 2014 -0800 intel_pstate: Add trace point to report internal state. Add perf trace event "power:pstate_sample" to report driver state to aid in diagnosing issues reported against intel_pstate. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> --- drivers/cpufreq/intel_pstate.c | 25 ++++++++++++++++++++ include/trace/events/power.h | 53 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index e8c3db8..4f82cfe 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -47,6 +47,8 @@ static inline int32_t div_fp(int32_t x, int32_t y) return div_s64((int64_t)x << FRAC_BITS, (int64_t)y); } +static u64 energy_divisor; + struct sample { int core_pct_busy; u64 aperf; @@ -444,6 +446,7 @@ static inline void intel_pstate_sample(struct cpudata *cpu) rdmsrl(MSR_IA32_APERF, aperf); rdmsrl(MSR_IA32_MPERF, mperf); + cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT; cpu->samples[cpu->sample_ptr].aperf = aperf; cpu->samples[cpu->sample_ptr].mperf = mperf; @@ -491,6 +494,7 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) ctl = pid_calc(pid, busy_scaled); steps = abs(ctl); + if (ctl < 0) intel_pstate_pstate_increase(cpu, steps); else @@ -500,10 +504,17 @@ static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu) static void intel_pstate_timer_func(unsigned long __data) { struct cpudata *cpu = (struct cpudata *) __data; + struct sample *sample; + u64 energy; intel_pstate_sample(cpu); + + sample = &cpu->samples[cpu->sample_ptr]; + rdmsrl(MSR_PKG_ENERGY_STATUS, energy); + intel_pstate_adjust_busy_pstate(cpu); + if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) { cpu->min_pstate_count++; if (!(cpu->min_pstate_count % 5)) { @@ -512,6 +523,15 @@ static void intel_pstate_timer_func(unsigned long __data) } else cpu->min_pstate_count = 0; + trace_pstate_sample(sample->core_pct_busy, + intel_pstate_get_scaled_busy(cpu), + cpu->pstate.current_pstate, + sample->mperf, + sample->aperf, + div64_u64(energy,energy_divisor), + sample->freq); + + intel_pstate_set_sample_time(cpu); } @@ -696,6 +716,7 @@ static int __init intel_pstate_init(void) { int cpu, rc = 0; const struct x86_cpu_id *id; + u64 units; if (no_load) return -ENODEV; @@ -717,8 +738,12 @@ static int __init intel_pstate_init(void) if (rc) goto out; + rdmsrl(MSR_RAPL_POWER_UNIT, units); + energy_divisor = 1 << ((units >> 8) & 0x1f); /* bits{12:8} */ + intel_pstate_debug_expose_params(); intel_pstate_sysfs_expose_params(); + return rc; out: get_online_cpus(); diff --git a/include/trace/events/power.h b/include/trace/events/power.h index 8e42410..735eb59 100644 --- a/include/trace/events/power.h +++ b/include/trace/events/power.h @@ -35,6 +35,59 @@ DEFINE_EVENT(cpu, cpu_idle, TP_ARGS(state, cpu_id) ); +TRACE_EVENT(pstate_sample, + + TP_PROTO(u32 core_busy, + u32 scaled_busy, + u32 state, + u64 mperf, + u64 aperf, + u32 energy, + u32 freq + ), + + TP_ARGS(core_busy, + scaled_busy, + state, + mperf, + aperf, + energy, + freq + ), + + TP_STRUCT__entry( + __field(u32, core_busy) + __field(u32, scaled_busy) + __field(u32, state) + __field(u64, mperf) + __field(u64, aperf) + __field(u32, energy) + __field(u32, freq) + + ), + + TP_fast_assign( + __entry->core_busy = core_busy; + __entry->scaled_busy = scaled_busy; + __entry->state = state; + __entry->mperf = mperf; + __entry->aperf = aperf; + __entry->energy = energy; + __entry->freq = freq; + ), + + TP_printk("core_busy=%lu scaled=%lu state=%lu mperf=%llu aperf=%llu energy=%lu freq=%lu ", + (unsigned long)__entry->core_busy, + (unsigned long)__entry->scaled_busy, + (unsigned long)__entry->state, + (unsigned long long)__entry->mperf, + (unsigned long long)__entry->aperf, + (unsigned long)__entry->energy, + (unsigned long)__entry->freq + ) + +); + /* This file can get included multiple times, TRACE_HEADER_MULTI_READ at top */ #ifndef _PWR_EVENT_AVOID_DOUBLE_DEFINING #define _PWR_EVENT_AVOID_DOUBLE_DEFINING -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c7 Thomas Renninger <trenn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |dirk.j.brandewie@intel.com --- Comment #7 from Thomas Renninger <trenn@suse.com> 2014-01-24 11:46:43 UTC --- Dirk: I probably cannot copy and paste the patch out of the website without losing formatting. Can you attach the patch, please. Best against 3.13, I will provide Jon with a lastest Kernel:stable build kernel then. Or even better: In general building kernels for testing is a burden you cannot put on an ordinary Linux user. Only a small percentage are really familiar with how to build and test kernels and even for them it is a huge waste of time. The patch looks very intel_pstate specific and I doubt that such a perf API will get accepted mainline. cpufreq had some nice debug facilities which now have been adopted to dynamic debugging using pr_debug(...). If you have a look at other cpufreq drivers (acpi_cpufreq, powernow-k8, ...), they are all clustered with such messages. It would be great to see intel_pstate extended to be able to enable debug facilities at runtime without the need of recompiling a kernel. If you could come up with such a patch, I can give it a review for mainline submitting and directly add it to our latest kernel HEAD version if it is likely to be accepted mainline. This would ease up intel_pstate debugging for us and others a lot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c8 --- Comment #8 from Dirk Brandewie <dirk.j.brandewie@intel.com> 2014-01-24 15:39:48 UTC --- Created an attachment (id=575759) --> (http://bugzilla.novell.com/attachment.cgi?id=575759) intel_pstate perf tracepoint -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c9 --- Comment #9 from Jon Nelson <jnelson-suse@jamponi.net> 2014-01-24 15:45:27 UTC --- I have built a great many kernels, however, I think Thomas Renninger is correct here insofar as most users aren't either capable or willing to undertake such a task. Either way is fine by me, but it's probably quicker to just wait for a package to try and we can go from there. Thanks so much to all parties for helping to improve my situation and by extension that of Linux in general! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c10 --- Comment #10 from Jon Nelson <jnelson-suse@jamponi.net> 2014-02-25 16:30:33 UTC --- Are there any updates here? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c11 --- Comment #11 from Borislav Petkov <bpetkov@suse.com> 2014-02-25 22:15:41 UTC --- Dirk, isn't that the same bug you posted a fix to, today: http://lkml.kernel.org/r/1393353337-19778-1-git-send-email-dirk.j.brandewie@... ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c12 --- Comment #12 from Dirk Brandewie <dirk.j.brandewie@intel.com> 2014-02-26 15:05:05 UTC --- (In reply to comment #11)
Dirk, isn't that the same bug you posted a fix to, today:
http://lkml.kernel.org/r/1393353337-19778-1-git-send-email-dirk.j.brandewie@...
?
It is possible but the regression fixed by the commit came in at v3.14-rc3. Likely you need commit: d253d2a intel_pstate: Improve accuracy by not truncating until final result I recently pushed this patch and other bug fixes to stable v3.10.y v3.12.y and v3.13.y. v3.11 stable was not included since it hasn't be updated since Nov. A quick way to see if you are seeing the issue fixed by the above commit is to change the setpoint of the PID with the command: echo 90 > /sys/kernel/debug/pstate_snb/setpoint -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c13 Timothy Butterworth <timothy.m.butterworth@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timothy.m.butterworth@gmail | |.com --- Comment #13 from Timothy Butterworth <timothy.m.butterworth@gmail.com> 2014-02-26 15:42:26 UTC --- As the 3.11.10 Kernel is no longer under support by The Kernel Foundation please bump openSUSE 13.1 up to the latest 3.12.x release. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c14 --- Comment #14 from Borislav Petkov <bpetkov@suse.com> 2014-02-26 16:12:44 UTC --- (In reply to comment #12)
It is possible but the regression fixed by the commit came in at v3.14-rc3.
Likely you need commit: d253d2a intel_pstate: Improve accuracy by not truncating until final result
I recently pushed this patch and other bug fixes to stable v3.10.y v3.12.y and v3.13.y. v3.11 stable was not included since it hasn't be updated since Nov.
Right, so from looking at d253d2a52676cfa3d89b8f0737a08ce7db665207, and at the korg bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=60727, it sounds very similar to what Jon is reporting. So it sounds like it would make sense to apply d253d2a to the opensuse 3.11 kernel, right? And, if you have other bugfixes in mind which should be applied to 3.11, let me know.
A quick way to see if you are seeing the issue fixed by the above commit is to change the setpoint of the PID with the command: echo 90 > /sys/kernel/debug/pstate_snb/setpoint
This is something Jon could try afterwards. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c Ihno Krumreich <ihno@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Other |openSUSE 13.1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c15 Thomas Renninger <trenn@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|dirk.j.brandewie@intel.com | AssignedTo|trenn@suse.com |bpetkov@suse.com --- Comment #15 from Thomas Renninger <trenn@suse.com> 2014-06-17 15:40:28 UTC --- While cleaning up bugs before holidays I stumbled over this one:
So it sounds like it would make sense to apply d253d2a to the opensuse 3.11 kernel, right? Boris: Still like to add this one? Or is it in already?
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c16 Borislav Petkov <bpetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |jnelson-suse@jamponi.net --- Comment #16 from Borislav Petkov <bpetkov@suse.com> 2014-06-19 11:52:38 UTC --- Jon, can you try this:
A quick way to see if you are seeing the issue fixed by the above commit is to change the setpoint of the PID with the command: echo 90 > /sys/kernel/debug/pstate_snb/setpoint
to check whether it fixes your issue before we apply the fix? Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=859809 https://bugzilla.novell.com/show_bug.cgi?id=859809#c17 Borislav Petkov <bpetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |CLOSED InfoProvider|jnelson-suse@jamponi.net | Resolution| |NORESPONSE --- Comment #17 from Borislav Petkov <bpetkov@suse.com> 2014-08-22 04:31:13 UTC --- Timeout, closing. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com