Bug 56071
Summary: | Ondemand doesn't set correct low frequency | ||
---|---|---|---|
Product: | Power Management | Reporter: | Francescodario Cuzzocrea (bosconovic) |
Component: | cpufreq | Assignee: | cpufreq |
Status: | CLOSED DOCUMENTED | ||
Severity: | normal | CC: | lenb, trenn |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.9.0 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | output of cpufreq |
Description
Francescodario Cuzzocrea
2013-04-01 20:12:23 UTC
Created attachment 96931 [details]
output of cpufreq
I also notice a global decreasing of performances when I plug AC, and everything start to lag on my desktop, I can provide video. I don't know if this is related to bug #56081. Thank you. On Tue, Apr 2, 2013 at 1:42 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > I've a samsung NP535U3C, powered by AMD A6-4455M APU. Cpupower tells to me > that > the lower frequency reachable by my CPU is 900 MHz but ondemand governor > switch > only between 1.3 and 2.1 GHz and not between 900 MHz and 2.1GHz as it should > be. I've also tried to set userspace governor to work between those > frequencies > but didn't work. Attached there is my cpupower frequency-info output. Thank > you. Your command gives you: limiti hardware: 1.30 GHz - 2.10 GHz I can make out from the above that your cpufreq driver gave min freq possible as 1.3 GHz. Borislav/Thomas, You have any idea about why this can happen? Francescodario, BTW you have any idea from what kernel version this happened? Hi and thank you for your reply ! Yes, my cpufreqdriver gave the min freq possible to 1.3 GHz, but according to my CPU specs should be 900 MHz. I've no idea of why this happen, I've tried everything I can do, like switch to userspace governor and se frequencies by myself, or set those frequencies in /etc/default/cpupower but nothing worked, I always get minumum frequency as 1.30 Ghz. I bought this laptop in December, and this always happened, I've tried 3.5 branch, 3.6 branch, 3.7 branch and 3.8 branch. Now I'm on 3.9rc4. > limiti hardware: 1.30 GHz - 2.10 GHz
This should not be possible.
The interface to limit frequency is a number.
For example 0 means no limitation, 1 means the highest frequency is limited.
Ah wait, I think I know what happens.
This is read out from the HW (and applies to CPU specs):
Boost States: 2
Total States: 7
Pstate-Pb0: 2600MHz (boost state)
Pstate-Pb1: 2300MHz (boost state)
Pstate-P0: 2100MHz
Pstate-P1: 1800MHz
Pstate-P2: 1500MHz
Pstate-P3: 1300MHz
Pstate-P4: 900MHz
This is done to be able to show available boost states and is normally hidden, also the kernel does not know about this!
The kernel gets the supported CPU frequency table from the BIOS via ACPI.
And your BIOS vendor decided to hide the 900MHz.
That's ok, because on latest CPUs (and your one probably is a rather new platform, because it supports boost states and therefore also suppports C-, CPU sleep states) the kernel will enter deep sleeps states when idle which is even more efficient than 900MHz CPU frequency.
I already close this one documented.
Everything works as designed.
Thank you for the reply and for clarifying to me how the kernel work ! Buth what about the global decreasing of performances when AC is plugged in ? Is this also related to cpufreq ? Here is a video of what I'm talking about : https://www.youtube.com/watch?v=tg2Jpuw_F_o > Is this also related to cpufreq ?
This is certainly ACPI related.
It's hard to guess, but your BIOS seem to request to limit cpufreq or throttling.
Cpufreq limitation you should see in this line:
limiti hardware: 1.30 GHz - 2.10 GHz
from cpupower frequency-info output.
This should be 1.30 GHz - 1.30 GHz
or similar after you plugged in AC.
Best you increase ACPI debug output before plugging AC:
echo 0x20f >/sys/module/acpi/parameters/debug_level
echo 0xffffffff >/sys/module/acpi/parameters/debug_layer
then do the plugging, wait a second or two and reduce debugging again.
echo 0 >/sys/module/acpi/parameters/debug_level
echo 0 >/sys/module/acpi/parameters/debug_layer
This could produce quite some kernel output, so you may want to boot with log_buf_len=16M
boot parameter.
Then attach dmesg and acpidump of your machine to the bug you created for the AC issue (mixing up bugs is confusing if you add other people later).
Before you start with all this, make sure you have the latest BIOS installed.
ACPI bugs can be tricky, best follow instructions of Lan Tianyu.
Feel free to add me to CC.
|