Most recent kernel where this bug did not occur: N/A (acpi-cpufreq would not load on previous versions) Distribution: Kubuntu 7.04 x86-64 Hardware Environment: Intel Core 2 Quad Q6600, XFX NForce 650i Ultra mainboard (with latest BIOS) Software Environment: Stock Kubuntu 7.04 with security updates Problem Description: Cpufreq did not work at all on this setup on the Kubuntu stock kernel (2.6.20), so I built 2.6.22-rc3, with Ubuntu config (updated with make oldconfig). Now acpi-cpufreq loads, but cpufreq-info reports: """" available frequency steps: 44.61 GHz, 29.74 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 29.74 GHz and 29.74 GHz. """ /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies lists: """ 44613000 29742000 """ Manually changing the governor to "userspace" and changing the frequency with echo 44613000 > scaling_cur_freq changes the reported current frequency, but has no effect on system performance (verified with simple benchmarks). Cpu frequency management is enabled in the BIOS. Scaling works fine on Windows XP Pro. Steps to reproduce:
Full /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping : 7 cpu MHz : 29742.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 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 pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4803.15 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 Quad CPU @ 2.40GHz stepping : 7 cpu MHz : 29742.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 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 pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4800.03 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping : 7 cpu MHz : 29742.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 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 pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4800.03 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping : 7 cpu MHz : 29742.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 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 pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4800.06 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
cpufreq-info output: cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 hardware limits: 29.74 GHz - 44.61 GHz available frequency steps: 44.61 GHz, 29.74 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 29.74 GHz and 29.74 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 29.74 GHz (asserted by call to hardware). analyzing CPU 1: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 1 hardware limits: 29.74 GHz - 44.61 GHz available frequency steps: 44.61 GHz, 29.74 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 29.74 GHz and 29.74 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 29.74 GHz (asserted by call to hardware). analyzing CPU 2: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 2 hardware limits: 29.74 GHz - 44.61 GHz available frequency steps: 44.61 GHz, 29.74 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 29.74 GHz and 29.74 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 29.74 GHz (asserted by call to hardware). analyzing CPU 3: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 3 hardware limits: 29.74 GHz - 44.61 GHz available frequency steps: 44.61 GHz, 29.74 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 29.74 GHz and 29.74 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 29.74 GHz (asserted by call to hardware).
please attach (do not paste) the output from acpidump, and the output from dmesg -s64000
Created attachment 12591 [details] acpidump hexdump format output I was not sure whether you wanted the hexdump or binary format, so I have attached both.
Created attachment 12592 [details] acpidump -b output
Created attachment 12593 [details] dmesg -s64000 output
[ 19.894654] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node ffff8100378b5220), AE_ALREADY_EXISTS [ 19.894664] ACPI: Marking method _PDC as Serialized [ 19.894715] ACPI: Processor [CPU0] (supports 8 throttling states) [ 19.894816] ACPI: SSDT 7FEF80C0, 0152 (r1 PmRef Cpu1Ist 3000 INTL 20040311) [ 19.895031] ACPI: SSDT 7FEF8220, 0152 (r1 PmRef Cpu2Ist 3000 INTL 20040311) [ 19.895243] ACPI: SSDT 7FEF8380, 0152 (r1 PmRef Cpu3Ist 3000 INTL 20040311) Please attach three files with the output from: acpidump --addr 0x7FEF80C0 --length 0x152 acpidump --addr 0x7FEF8220 --length 0x152 acpidump --addr 0x7FEF8380 --length 0x152
SSDT2.dsl: Name (CFGD, 0x780783F2) // dunno if the run-time SSDT's change this or not, but lets assume // that they don't until we see them... SSDT1.dsl: Method (_PSS, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (SPSS) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (NPSS) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (NPSS) // we should come here, based on CFGD value above } Return (SPSS) } ... but in either case, the BIOS really is reporting 44 GHz and 29 GHz: Name (SPSS, Package (0x02) { Package (0x06) { 0x0000AE45, // 44613 MHz 0x000157C0, 0x000000A0, // latency = 160usec, consistent with I/O? 0x0000000A, 0x00000036, // ctl 0x00000000 }, Package (0x06) { 0x0000742E, // 29742 MHz 0x0000F230, 0x000000A0, // latency = 160usec, consistent with I/O? 0x0000000A, 0x00000136, // ctl 0x00000001 } }) Name (NPSS, Package (0x02) { Package (0x06) { 0x0000AE45, // 44613 MHz 0x000157C0, 0x0000000A, // latency = 10usec -- consistent with MSR 0x0000000A, 0x00000923, // ctl 0x00000923 }, Package (0x06) { 0x0000742E, // 29742 MHz 0x0000F230, 0x0000000A, -- latency = 10usec -- consistent with MSR 0x0000000A, 0x0000061B, // ctl 0x0000061B } }) How did you verify that scaling is working on XP? Can you verify that the BIOS for this board supports this processor?
I will attach the requested files when I get home from work today (the machine in question is my home machine). I verified that scaling was working in XP using the CPU-Z utility, SpeedFan and the nTune utility from Nvidia. All show the processor multiplier and CPU clock being reduced from 9 (9x 1066/4 = 2400MHz) to 6 (6x1066/4 = 1600MHz) and back up when I start, for example, Prime95. This page from the vendor: http://www.xfxforce.com/web/product/listConfigurations.jspa?series=NVIDIA+nForce+650i&seriesId=989307 lists "Core 2 Quad" as being supported. Q6600 was one of the first quads launched, so I assumed that was included. Thanks for your help so far. If the SSDT is reporting the wrong frequencies, should I contact XFX and ask for a new BIOS?
Created attachment 12612 [details] acpidump outputs requested by Len Brown in comment #7
Hi, Marc Thanks for the info. What Len said in comment #8 is very right. The available cpu frequency is obtained from PSS package. Because the PSS package is wrong , the cpuinfo will report the wrong frequency after cpufreq module is loaded. At the same time there is another problem about the system. ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node ffff8100378b5220), AE_ALREADY_EXISTS The reason about this error message is listed in the following: In the initialization of acpi_processor_init the PDC method will be called,in which the AML will load table from the address of 0x7fef8b80 dynamically. Unfortunately the SSDT table at the address of 0x7fef8b80 has been loaded in the acpi_early_init. So the system will print the error info ---"AE_ALREADY_EXIST".
The problem in thi bug is that /proc/cpuinfo reports wrong frequency. The flowchart of /proc/cpuinfo is listed the following: a. Before the cpufreq module is loaed, the /proc/cpuinfo will use the cpu_khz to display the cpu frequency. And cpu_khz is obtained using TSC calculation in the initialization of OS. b. After the cpufreq module is loaded, the /proc/cpuinfo will display the cpu frequency obtained from the P-states table. The P-states table in this system is uncorrect. Package (0x06) { 0x0000AE45, // 44613 MHz 0x000157C0, 0x0000000A, // latency = 10usec -- consistent with MSR 0x0000000A, 0x00000923, // ctl 0x00000923 }, Package (0x06) { 0x0000742E, // 29742 MHz 0x0000F230, 0x0000000A, -- latency = 10usec -- consistent with MSR 0x0000000A, 0x0000061B, // ctl 0x0000061B } So the /proc/cpuinfo will report the wrong cpu frequency after the cpufreq module is loaded. It is appropriate to fix this problem by BIOS update.
> It is appropriate to fix this problem by BIOS update. Thank you (and the other developers) very much. I will contact the vendor (XFX) and request a BIOS update to fix this issue.