Hello! I use a laptop with Mobile AMD Sempron processor and I've been experiencing the following problem since kernel version 2.6.30: When I work from AC power adapter, everything is fine - the whole set of frequencies for my processor are avalable (namely, 800 MHz, 1600MHz, 1800MHz, 2000MHz and 2200MHz). When I unplug the AC adapter, the CPU switches to 800MHz mode and I cannot make it use any of the higher frequencies. I know for sure that this worked fine with kernel v.2.6.29. This is very inconvenient - to use the lowest available frequency every time I work from the battery. I have reported this bug to Gentoo Bugzilla at first. Here is the link: http://bugs.gentoo.org/show_bug.cgi?id=328395 There are some details on this story on that page. I hope the bug (if it is one) will be fixed soon. Thanks. Vladimir.
Please check your BIOS for an option like "powersave", "powersave on battery" or somehow related to this. If you do not find it read up the BIOS manual, possibly do a BIOS upgrade first if you really do not find anything.
I close this one invalid already, as this is most probably a BIOS issue, this even sounds intended.
Hello! I'm not sure if it is a BIOS problem, since like I have already said above, this works properly with 2.6.29 kernel (I double-checked it today). It fails with newer kernels with the very same BIOS settings. If two different kernels behave differently with exactly the SAME BIOS settings, could it be the BIOS issue? Thanks.
This is because previous kernels did not read out the BIOS limit at processor.ko load time which was wrong and got fixed. The reason why the BIOS limits freq can be totally different, e.g. here: https://bugzilla.kernel.org/show_bug.cgi?id=16362 It gets limited on ThinkPads if you work with a 65 Watts AC adapter without battery. Or you might want to read the last comments of vyncere in this bug (the bug is about something else, but that was not clear at the beginning): https://bugzilla.kernel.org/show_bug.cgi?id=19702 ------------------- Thank you very much Thomas for your hint. As you suggested me to check the BIOS limit (which was 1.20 GHz in my case), this morning I set in my BIOS for all modes (AC/DC Power + Battery) the "Performance" profile, instead of "Power-saving" one. Now the BIOS limit is 2.40GHz, and cpufreq manage to do his job, without any patches (2.6.36). ------------------- I looked at quite some "Bios limits my frequency" bugs and the kernel always behaved correct. If your ACPI tables are not busted (and you should see this by some obvious ACPI Error messages in dmesg), I suggest you look up your BIOS setting, your mainboard manual or update the BIOS if it does not help.
> If your ACPI tables are not busted (and you should see this by some obvious > ACPI Error messages in dmesg Not really true, if there is a logical bug, but syntax, etc. in ACPI code is correct you may not see an error message. But ACPI interpreting works pretty well these days and chances that the limit is wanted by the OEM for whatever reasons are high. You can override the BIOS limit by the boot param: processor.ignore_ppc=1 But instead of using this all day, you should better find out why the BIOS vendor/OEM limits your frequency, there is certainly a reason for it. Above helps (and this is hopefully what the bug is about) only if you see the limit here: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit If your frequency is restricted/limited due to other reasons, please open a new bug and state it in the description to avoid confusion and mix ups of several problems in one bug. Hmm, there were quite some people in CC of this bug. I'd be interested how much get fixed by BIOS settings, etc.. I keep the bug open for a while, even I am pretty sure most/all people seeing BIOS frequency limits is *not* due to a kernel bug.
(In reply to comment #5) > Above helps (and this is hopefully what the bug is about) only if you see the > limit here: > /sys/devices/system/cpu/cpu0/cpufreq/bios_limit > Yes, this is my case. I also mentioned this file in my bugreport on Gentoo Bugzilla (the link to that bugreport is in the first message of this thread). I do not remember the older kernels (before 2.6.30) to provide this file. And like I said before, this file does store the lowest possible CPU frequency with AC adapter off. I have found a BIOS feature "Andvanced power management", but triggering it has no effect. I don't really know what is this feature for. So, there is no way to change this behaviour tweaking the BIOS settings.
> I have found a BIOS feature "Andvanced power management" Sounds related. > I don't really know what is this feature for Yep, finding out why the BIOS sets the frequency limit can be cumbersome. Still, it's not a kernel, but a BIOS/platform issue. As said, all initial BIOS limits were ignored by the kernel for quite some time and this got fixed. Have you looked for BIOS updates and their changelogs already? If not, this would be the next step. If this also does not help, please attach acpidump output (with the new BIOS!). Be aware that this is very low prio bug, as it's very likely that the culprit (most likely this is even intended) comes from the BIOS.
(In reply to comment #7) > > I have found a BIOS feature "Andvanced power management" > Sounds related. Well, I thik so too, but I tried to switch this option on/off several times, and naven't noticed any changes in anything. This feature is also not documented in the User's Manual for my laptop. > Still, it's not a kernel, but a BIOS/platform issue. Yes. Now I'm sure this isn't a kernel issue. I tried to add the "processor.ignore_ppc=1" string to the kernel parameters at startup, just like you suggested, and it really gave me access for all the CPU frequencies, which is just great! Thank you for this tip! :) > As said, all initial BIOS limits were ignored by the kernel for quite some > time > and this got fixed. Have you looked for BIOS updates and their changelogs > already? If not, this would be the next step. Yes, I have looked for the BIOS updates, but there are no updates to fix this strange behaviour. Moreover, I have been searching trough some fora these days and I see people saying that MSI (my laptop vendor) knows about this problem and says that "this is a company design policy of this model". This means they refuse to fix the bug in their BIOS and release an update, I guess. There are also many Windows users who experience the same problem and they found some software to tweak this on Windows too. > If this also does not help, please attach acpidump output (with the new > BIOS!). > Be aware that this is very low prio bug, as it's very likely that the culprit > (most likely this is even intended) comes from the BIOS. Well, now it certainly is BIOS to blame. Thus it seems to me this bug may be closed already. I think that now it is a question of spreading the information about "processor.ignore_ppc" parameter. At least for operating systems using Linux as their kernel. Oh, and by the way, I have found on some Debian-related forum that this behaviour may be tweaked during run-time also by executing the following command: echo 1 > /sys/module/processor/parameters/ignore_ppc