I have an asus laptop, F5Sr-AP087E, with an Intel Core 2 Duo P7350 @ 2.0GHz but acpi_cpufreq, which is the driver loaded for changing the P-states, remains stuck at 1.34 GHz, even that windows vista business 32 changes the processors freqs from 2 GHz to 1.4 GHz through 1.6 and 1.8 GHz that I've seen. Any attempts to change manually the frequency bounds has been useless. /proc/cpuinfo, cpufreq-info, etc.. all show only that freq as available but dmesg shows its maximum is 2 GHz and that it has 8 throttling states. I have a Debian testing (squeeze) for x86_64 with both testing (2.6.26) and unstable (2.6.29) kernel.
Created attachment 21901 [details] cpufreqd -D -V7 output
Created attachment 21902 [details] dsdt file
Created attachment 21903 [details] dmesg output
Created attachment 21904 [details] various system information (dmidecode, lsmod, lspci ...)
I've read somewhere online that it maybe is a bios problem. I don't know how to identify it. Neither Asus nor Debian have this bug identified (or I have not managed to find it).
Will you please attach the output of acpidump? Will you please enable the "CONFIG_CPU_FREQ_DEBUG" in kernel configuration and attach the boot option of "cpufreq.debug=7"? After the system is booted, please attach the output of dmesg. It will be great if you can attach the following outputs. acpidump --addr 0xBFFB78B0 --length 0C9A -o cpu0 acpidump --addr 0xBFFB8550 --length 0C9A -o cpu1 Thanks.
please attach the output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*"
Created attachment 21920 [details] acpidump output
Created attachment 21921 [details] output of acpidump for cpu0
Created attachment 21922 [details] output of acpidump for cpu1
Created attachment 21923 [details] output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" I'm going to reconfigure my kernel for the debug information you asked.
Created attachment 21924 [details] dmesg output with cpufreq.debug=7
please boot the system in "acpi=off" mode and re-run these commands: acpidump --addr 0xBFFB78B0 --length 0C9A -o cpu0-acpioff acpidump --addr 0xBFFB8550 --length 0C9A -o cpu1-acpioff It seems that these tables are being initialized improperly, and if the acpi=off version of them shows something different than what you collected above, that supports that the initialization is happening at boot-time and not BIOS-compile-time. --- is it possible to make a more concrete observation on Windows about which frequencies it is exposing and supporting? (eg. run permon and perhaps windows has some processor stats that will display the frequency?)
just for the record, it appears that acpi-cpufreq is accurately processing what the system exports in its _PSS acpi table, but that table has only 2 states (many duplicates) and it is in the wrong order -- the high MHz is supposed to come first: [ 12.256812] acpi-cpufreq: acpi_cpufreq_cpu_init [ 12.260343] acpi-cpufreq: HARDWARE addr space [ 12.260346] freq-table: table entry 0: 1344000 kHz, 0 index [ 12.260348] acpi-cpufreq: get_cur_freq_on_cpu (0) [ 12.260358] acpi-cpufreq: get_cur_val = 100665122 [ 12.260359] acpi-cpufreq: cur freq = 1344000 [ 12.260362] acpi-cpufreq: CPU0 - ACPI performance management activated. [ 12.260364] acpi-cpufreq: *P0: 1344 MHz, 27000 mW, 10 uS [ 12.260367] acpi-cpufreq: P1: 1600 MHz, 10800 mW, 10 uS [ 12.260369] freq-table: setting show_table for cpu 0 to ffff8800bcc4caa0 [ 12.260385] cpufreq-core: setting new policy for CPU 0: 1344000 - 1344000 kHz
> (eg. run permon and perhaps windows has some processor stats > that will display the frequency?) typo, "permon" should be "perfmon".
Created attachment 21933 [details] output of acpidump for cpu0 (acpi=off)
Created attachment 21934 [details] output of acpidump for cpu1 (acpi=off)
Created attachment 21935 [details] dmesg with "cpufreq.debug=7 acpi=off"
Created attachment 21936 [details] /proc/cpuinfo with acpi=off Now it only recognises 1 cpu but it's frequency is the theoretical maximum.
can you run the perfmon in windows and see if windows is using multiple p-states?
Agree with what Len said in comment #14. It seems that the frequency in _PSS package is in ascending order. But according to ACPI spec it should be the descending order. From the dmesg log it seems that two P-states are reported by the _PSS package. But unfortunately the second P-state is removed by the following code, which causes that only one P-state is remained in the frequency table. So it will always use the lowest frequency. >/* table init */ for (i = 0; i < perf->state_count; i++) { if (i > 0 && perf->states[i].core_frequency >= data->freq_table[valid_states-1].frequency / 1000) continue; /* If the current frequency is larger or equal to the previous frequency, it will be skipped */ data->freq_table[valid_states].index = i; Maybe we should initialize the frequency table correctly even when the frequency in _PSS is in ascending order. Thanks.
I've been trying the perfmon in windows. I'm not sure if they are p-states but it reports a variation in frequency when changing power saving governors. It doesn't change dynamically by itself. The variations I reported I had seen where when I had a powersaving program for windows, HWClock. Although I'm using now the CPU-Z utility which reported a frequency of 2 GHz at maximum performance and only reported 1 cpu in windows. I hope this brings some light finally whether it's a bug or not. I actually have the source for 2.6.30, I can try compiling and installing it too if you like.
Created attachment 22043 [details] Sort the ACPI P-state table in descending order by cpufreq Will you please try the attached patch on the latest kernel and see whether the other cpufreq is used besides 1344MHZ? In this patch the ACPI P-state table is sorted in descending order by cpufreq. Please boot the system with "cpufreq.debug=7" and attach the output of dmesg. Thanks.
I'm sorry, I'm pretty new but, how do I apply the patch? By the way I've tried 2.6.30 and it keeps the same problem.
Created attachment 22044 [details] dmesg output with cpufreq.debug=7 (2.6.30 patched) I've patched the 2.6.30 kernel. I'll patch the 2.6.29 and upload its dmesg too. Not solved in 2.6.30.
Created attachment 22045 [details] dmesg output with cpufreq.debug=7 (2.6.29 patched)
Created attachment 22075 [details] Sort the ACPI P-state table in descending order by cpufreq Will you please try the updated patch and see whether the issue still exists? I am sorry that the incorrect patch is attached. Thanks.
Created attachment 22076 [details] Sort the ACPI P-state table in descending order by cpufreq Please try the updated patch. Thanks.
Created attachment 22080 [details] dmesg output with cpufreq.debug=7 (2.6.30 patched2) Actually it works. Now it recognises two available frequencies 1.60 and 1.34 GHz. The other problem I reported was that those frequencies aren't all the theoretically available and that neither of those is the expected top frequency. I'll appreciate if you want to keep working on them.
Created attachment 22081 [details] cpufreq-info output in 2.6.30patched2 Sorry, I was too eager. Actually it recognises the two frequencies as avilable, but cpufreq remains stuck using the lowest only.
Created attachment 22082 [details] dmesg output with cpufreq.debug=7 (2.6.29 patched2) This one doesn't work. It keeps not listing other available frequencies. 2.6.30 does list other available frequencies.
From the log in comment #29 it seems that two available frequency(1600 and 1344MHz) are reported after applying the patch. This is what I expected. Another problem is that the highest cpufreq(2GHZ) is not reported. Right? From the acpidump we know that only two cpu frequencies are reported by the BIOS.(1600 and 1344MHz). And we can do nothing to fix it. But from the log in comment #31 still only one cpufreq is used on the 2.6.29 kernel. Will you please try it again? Thanks.
Created attachment 22093 [details] dmesg output with cpufreq.debug=7 (2.6.29 patched2) Here is the correct 2.6.29patched2 dmesg. It lists the two available frequencies too. Also, are the cpufreq utilities (cpufreq-info and cpufreq-set) yours? Because even if I change the governor it will be stuck allowing only one frequency (1.6 this time) as you can see in attachent 22081.
Attachment 22081 [details] is in comment #30
Thanks for the test. Now it seems that two cpu frequency can be used on the 2.6.29 kernel. This is what we expected. In such case the cpufreq driver can work well and switch the cpufreq according to the different cpufreq governor. But the highest cpufreq(2GHz) is still not reported. This issue is related with the BIOS. And we can do nothing to fix it. So this bug is marked as resolved. Thanks.
Thank you too, now I know I have a problem with the bios and when I solve it I'll not have any other because you solved this one. Thank you very much.