Re: cpufreq scaling appears not to work on overclocked systems
On Sun, Jul 29, 2007 at 03:16:45PM -0600, Berck E. Nash wrote: > I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is > normal with cpufreq scaling disabled. With cpufreq scaling enabled in > the kernel, using any governor, /proc/cpuinfo indicates a maximum of the > rated frequency rather than the actual frequency. FAQ. The BIOS contains hard coded tables of frequencies. Just because you changed the clocks on which those tables are based doesn't mean the tables will change. Not a bug. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpufreq scaling appears not to work on overclocked systems
This is not new, but exists as far back as 2.6.17. I haven't reported it before because I figured that surely someone else had noticed it, but since it's still unfixed and I cannot find any mention of it on LKML, here we go. I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is normal with cpufreq scaling disabled. With cpufreq scaling enabled in the kernel, using any governor, /proc/cpuinfo indicates a maximum of the rated frequency rather than the actual frequency. Here it is under 100% utilization, with userspace governor and powernowd: [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 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 syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5134.39 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 : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 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 syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5131.64 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: At idle it drops down to 1596.000 MHz reported. At boot the kernel doest report the correct frequency (2564.907), which agrees with the bogomips reported by /proc/cpuinfo as well. I haven't done any benchmarking to try to determine if perhaps freq scaling works as it should and just the reported frequency is incorrect. Berck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpufreq scaling appears not to work on overclocked systems
This is not new, but exists as far back as 2.6.17. I haven't reported it before because I figured that surely someone else had noticed it, but since it's still unfixed and I cannot find any mention of it on LKML, here we go. I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is normal with cpufreq scaling disabled. With cpufreq scaling enabled in the kernel, using any governor, /proc/cpuinfo indicates a maximum of the rated frequency rather than the actual frequency. Here it is under 100% utilization, with userspace governor and powernowd: [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 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 syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5134.39 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 : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 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 syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5131.64 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: At idle it drops down to 1596.000 MHz reported. At boot the kernel doest report the correct frequency (2564.907), which agrees with the bogomips reported by /proc/cpuinfo as well. I haven't done any benchmarking to try to determine if perhaps freq scaling works as it should and just the reported frequency is incorrect. Berck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq scaling appears not to work on overclocked systems
On Sun, Jul 29, 2007 at 03:16:45PM -0600, Berck E. Nash wrote: I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is normal with cpufreq scaling disabled. With cpufreq scaling enabled in the kernel, using any governor, /proc/cpuinfo indicates a maximum of the rated frequency rather than the actual frequency. FAQ. The BIOS contains hard coded tables of frequencies. Just because you changed the clocks on which those tables are based doesn't mean the tables will change. Not a bug. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
