Most recent kernel where this bug did not occur: 2.6.22 Distribution: Gentoo Hardware Environment: Intel E4300, Asus P5KC Software Environment: Problem Description: I run the CPU out of its specification at 3GHz. When I load acpi_cpufreq /proc/cpuinfo shows the wrong speed. It shows 1,8 GHz which would be the CPU's normal speed at a FSB of 200 MHz (but I'm running 333 MHz). Without acpi_cpufreq loaded cpuinfo says the correct speed of 3 GHz. I also benchmarked the CPU while acpi_cpufreq was loaded. It definetly runs at 3GHz. Steps to reproduce: # grep MHz /proc/cpuinfo cpu MHz : 3005.555 cpu MHz : 3005.555 # modprobe acpi_cpufreq # grep MHz /proc/cpuinfo cpu MHz : 1800.000 cpu MHz : 1800.000
> Most recent kernel where this bug did not occur: 2.6.22 Sorry, this was wrong. It does occur in 2.6.22.
Reply-To: akpm@linux-foundation.org On Thu, 13 Sep 2007 17:18:49 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > KernelVersion: 2.6.22 > Most recent kernel where this bug did not occur: 2.6.22 These two facts are contradictory. Please tell us the most recent kernel where this bug did not occur
>> KernelVersion: 2.6.22 >> Most recent kernel where this bug did not occur: 2.6.22 > > These two facts are contradictory. Yes, I know. I read the presets of this form to fast. It occured in 2.6.22, so I don't have any more recent kernel installed where it would not occur.
Please attach the acpidump output. Thanks.
Created attachment 12847 [details] acpidump
(In reply to comment #5) > Created an attachment (id=12847) [details] > acpidump > Hi, Markus Thanks for the info. It should be noted that this is not real bug. If the cpu_freq driver isn't loaded, the cpuinfo uses the current running frequency, which is gotten through the cpu hardware. But if the cpu_freq driver is loaded, the cpuinfo uses the frequency obtained from the BIOS according to the system state. Since you overclock the cpu, cpuinfo will report the predefined cpufrequency(1.8G) in BIOS other than the current running frequency(3.0G) after cpu_freq driver is loaded. Anyway, Please get some info using the following commands: acpidump --addr 0x7ff8e0d0 --length 0x1d2 -o stb1 acpidump --addr 0x7ff8e2b0 --length 0x143 -o stb2
Created attachment 12852 [details] acpidump --addr 0x7ff8e0d0 --length 0x1d2 -o stb1
Created attachment 12853 [details] acpidump --addr 0x7ff8e2b0 --length 0x143 -o stb2
Hi, Markus From the info of comment #8 the predefined cpufreq in BIOS is 1800MHz(0x708) and 1200Mhz(0x4b0). Before cpufreq driver is loaded, cpuinfo uses the current running frequency obtained using the CPU hardware. For example 3.0GHz. After cpufreq driver is loaded, cpuinfo uses the frequency obtained from BIOS(1800Mhz). So when cpufreq is loaded and cpu is overclocked, the cpuinfo will report the different frequency. But it is not wrong becuase OS doesn't know that cpu is overclocked. Thanks for the info.
The folliwng is added for the comment #9: 1. In the boot phase OSPM will detect the cpu frequency and store the result to cpu_khz. The /proc/info will use the cpu_khz to display the cpu frequency before the cpufreq module is loaded. 2. In the previous kernel(for example 2.6.12) the /proc/info continues using the cpu_khz to display the cpu frequency after the cpufreq module is loaded. When the P-state is changed, the OSPM will update the cpu_khz using the function of cpufreq_scale.In this case even when the cpu is overclocked the OSPM can update the cpu_khz correctly. In smp system when the CPUs run in different p-states , the /proc/info for all cpus will display the same frequency.It is uncorrect. Of course there is no problem when the all cpus run in the same P-states. So in the current kernel the above method is discarded and the /proc/info displays the cpu freqency obtained from the P-state table. It can still display the cpu frequency correctly when all cpus run in different p-states. Of course there appears a new problem that OS can't display the cpu frequency correctly when overclocked.The problem can be solved by adding frequency ratio for every cpu. The frequency ration can be defined as : ratio = cpu_max_khz / cpu_khz_p0_states cpu_max_khz is calculated in the function of calibrate_delay. cpu_khz_p0_states is the max frequency in P0-states. But I think that it is unnecessary to fix this problem because the floating calculation will be involved.(The floating calculation can be avoided if two variables are added for every cpu. And it is complex).