Bug 13529 (mukik182) - Invalid min and max cpu frequencies
Summary: Invalid min and max cpu frequencies
Status: CLOSED DOCUMENTED
Alias: mukik182
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-13 20:33 UTC by Miguel Bernabeu Diaz
Modified: 2009-08-29 21:47 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.26, 2.6.29
Subsystem:
Regression: No
Bisected commit-id:


Attachments
cpufreqd -D -V7 output (36.13 KB, text/plain)
2009-06-13 20:34 UTC, Miguel Bernabeu Diaz
Details
dsdt file (28.62 KB, application/octet-stream)
2009-06-13 20:38 UTC, Miguel Bernabeu Diaz
Details
dmesg output (103.40 KB, text/plain)
2009-06-13 20:39 UTC, Miguel Bernabeu Diaz
Details
various system information (dmidecode, lsmod, lspci ...) (42.79 KB, text/plain)
2009-06-13 20:41 UTC, Miguel Bernabeu Diaz
Details
acpidump output (137.50 KB, text/plain)
2009-06-15 14:32 UTC, Miguel Bernabeu Diaz
Details
output of acpidump for cpu0 (3.15 KB, application/octet-stream)
2009-06-15 14:33 UTC, Miguel Bernabeu Diaz
Details
output of acpidump for cpu1 (3.15 KB, application/octet-stream)
2009-06-15 14:33 UTC, Miguel Bernabeu Diaz
Details
output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*" (1.70 KB, text/plain)
2009-06-15 14:35 UTC, Miguel Bernabeu Diaz
Details
dmesg output with cpufreq.debug=7 (67.76 KB, text/plain)
2009-06-15 15:51 UTC, Miguel Bernabeu Diaz
Details
output of acpidump for cpu0 (acpi=off) (3.15 KB, application/octet-stream)
2009-06-16 10:18 UTC, Miguel Bernabeu Diaz
Details
output of acpidump for cpu1 (acpi=off) (3.15 KB, application/octet-stream)
2009-06-16 10:19 UTC, Miguel Bernabeu Diaz
Details
dmesg with "cpufreq.debug=7 acpi=off" (41.55 KB, text/plain)
2009-06-16 10:20 UTC, Miguel Bernabeu Diaz
Details
/proc/cpuinfo with acpi=off (713 bytes, text/plain)
2009-06-16 10:22 UTC, Miguel Bernabeu Diaz
Details
Sort the ACPI P-state table in descending order by cpufreq (1.99 KB, patch)
2009-06-22 08:59 UTC, ykzhao
Details | Diff
dmesg output with cpufreq.debug=7 (2.6.30 patched) (62.92 KB, text/plain)
2009-06-22 13:28 UTC, Miguel Bernabeu Diaz
Details
dmesg output with cpufreq.debug=7 (2.6.29 patched) (67.55 KB, text/plain)
2009-06-22 14:35 UTC, Miguel Bernabeu Diaz
Details
Sort the ACPI P-state table in descending order by cpufreq (1.99 KB, patch)
2009-06-24 05:18 UTC, ykzhao
Details | Diff
Sort the ACPI P-state table in descending order by cpufreq (1.99 KB, patch)
2009-06-24 05:19 UTC, ykzhao
Details | Diff
dmesg output with cpufreq.debug=7 (2.6.30 patched2) (66.51 KB, text/plain)
2009-06-24 11:01 UTC, Miguel Bernabeu Diaz
Details
cpufreq-info output in 2.6.30patched2 (1.19 KB, text/plain)
2009-06-24 11:24 UTC, Miguel Bernabeu Diaz
Details
dmesg output with cpufreq.debug=7 (2.6.29 patched2) (70.02 KB, text/plain)
2009-06-24 11:41 UTC, Miguel Bernabeu Diaz
Details
dmesg output with cpufreq.debug=7 (2.6.29 patched2) (70.83 KB, text/plain)
2009-06-25 10:34 UTC, Miguel Bernabeu Diaz
Details

Description Miguel Bernabeu Diaz 2009-06-13 20:33:35 UTC
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.
Comment 1 Miguel Bernabeu Diaz 2009-06-13 20:34:52 UTC
Created attachment 21901 [details]
cpufreqd -D -V7 output
Comment 2 Miguel Bernabeu Diaz 2009-06-13 20:38:50 UTC
Created attachment 21902 [details]
dsdt file
Comment 3 Miguel Bernabeu Diaz 2009-06-13 20:39:44 UTC
Created attachment 21903 [details]
dmesg output
Comment 4 Miguel Bernabeu Diaz 2009-06-13 20:41:04 UTC
Created attachment 21904 [details]
various system information (dmidecode, lsmod, lspci ...)
Comment 5 Miguel Bernabeu Diaz 2009-06-13 20:44:25 UTC
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).
Comment 6 ykzhao 2009-06-15 00:50:58 UTC
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.
Comment 7 Zhang Rui 2009-06-15 02:15:30 UTC
please attach the output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*"
Comment 8 Miguel Bernabeu Diaz 2009-06-15 14:32:35 UTC
Created attachment 21920 [details]
acpidump output
Comment 9 Miguel Bernabeu Diaz 2009-06-15 14:33:34 UTC
Created attachment 21921 [details]
output of acpidump for cpu0
Comment 10 Miguel Bernabeu Diaz 2009-06-15 14:33:53 UTC
Created attachment 21922 [details]
output of acpidump for cpu1
Comment 11 Miguel Bernabeu Diaz 2009-06-15 14:35:10 UTC
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.
Comment 12 Miguel Bernabeu Diaz 2009-06-15 15:51:42 UTC
Created attachment 21924 [details]
dmesg output with cpufreq.debug=7
Comment 13 Len Brown 2009-06-16 02:11:35 UTC
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?)
Comment 14 Len Brown 2009-06-16 02:14:22 UTC
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
Comment 15 Zhang Rui 2009-06-16 02:17:06 UTC
> (eg. run permon and perhaps windows has some processor stats
>  that will display the frequency?)

typo, "permon" should be "perfmon".
Comment 16 Miguel Bernabeu Diaz 2009-06-16 10:18:57 UTC
Created attachment 21933 [details]
output of acpidump for cpu0 (acpi=off)
Comment 17 Miguel Bernabeu Diaz 2009-06-16 10:19:32 UTC
Created attachment 21934 [details]
output of acpidump for cpu1 (acpi=off)
Comment 18 Miguel Bernabeu Diaz 2009-06-16 10:20:36 UTC
Created attachment 21935 [details]
dmesg with "cpufreq.debug=7 acpi=off"
Comment 19 Miguel Bernabeu Diaz 2009-06-16 10:22:02 UTC
Created attachment 21936 [details]
/proc/cpuinfo with acpi=off

Now it only recognises 1 cpu but it's frequency is the theoretical maximum.
Comment 20 Zhang Rui 2009-06-17 05:22:22 UTC
can you run the perfmon in windows and see if windows is using multiple p-states?
Comment 21 ykzhao 2009-06-17 09:53:28 UTC
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.
Comment 22 Miguel Bernabeu Diaz 2009-06-17 13:40:03 UTC
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.
Comment 23 ykzhao 2009-06-22 08:59:34 UTC
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.
Comment 24 Miguel Bernabeu Diaz 2009-06-22 11:18:34 UTC
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.
Comment 25 Miguel Bernabeu Diaz 2009-06-22 13:28:45 UTC
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.
Comment 26 Miguel Bernabeu Diaz 2009-06-22 14:35:59 UTC
Created attachment 22045 [details]
dmesg output with cpufreq.debug=7 (2.6.29 patched)
Comment 27 ykzhao 2009-06-24 05:18:10 UTC
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.
Comment 28 ykzhao 2009-06-24 05:19:44 UTC
Created attachment 22076 [details]
Sort the ACPI P-state table in descending order by cpufreq

Please try the updated patch.

Thanks.
Comment 29 Miguel Bernabeu Diaz 2009-06-24 11:01:49 UTC
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.
Comment 30 Miguel Bernabeu Diaz 2009-06-24 11:24:34 UTC
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.
Comment 31 Miguel Bernabeu Diaz 2009-06-24 11:41:00 UTC
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.
Comment 32 ykzhao 2009-06-25 05:26:17 UTC
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.
Comment 33 Miguel Bernabeu Diaz 2009-06-25 10:34:40 UTC
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.
Comment 34 Miguel Bernabeu Diaz 2009-06-25 10:35:35 UTC
Attachment 22081 [details] is in comment #30
Comment 35 ykzhao 2009-06-26 02:05:50 UTC
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.
Comment 36 Miguel Bernabeu Diaz 2009-06-26 04:51:43 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.