With sys-kernel/gentoo-sources-2.6.34-r2 (and probably, some older versions) there is a file named /sys/devices/system/cpu/cpu0/cpufreq/bios_limit, in which the highest available (by BIOS) CPU frequency is stored. Everything seems to be fine when AC adapter if plugged into the laptop. When I turn off the AC adapter, the 'bios_limit' file stores the number 800000 (for 800MHz). And there is no ability to set the CPU frequency higher than this value. This is wrong and very inconvenient since there is often a need to use the higher frequencies (line 2,2GHz on my laptop) even when working on the battery only. Probably, it is important to say that with sys-kernel/gentoo-sources-2.6.29-gentoo-r6 there had been an ability to use the higher CPU frequencies even with AC adapter turned off. And also, I haven't seen the 'bios_limit' mentioned above with that kernel version (2.6.29). So, it looks like a regression from gentoo-sources-2.6.29. (my CPU is Mobile AMD Sempron (K8 family) and the 'powernow-k8' driver is built into the kernel) Reproducible: Always Steps to Reproduce: 1. emerge gentoo-sources-2.6.29 on a machine with AMD CPU. 2. Configure it to use powernow-k8 to scale the CPU frequency on the run. 3. Boot a system with this kernel and see the 'cpufreq-info' output. 4. Unplug the AC adapter and see the output of 'cpufreq-info' again and compare with the previous one. They should be the same. 5. emerge gentoo-sources-2.6.34-r2, copy the '.config' file from the previous case and build the kernel. 6. Boot a system with the new kernel and see the 'cpufreq-info' output. 7. Unplug the AC adapter and see the output of 'cpufreq-info' again and compare with the previous one. Actual Results: Now they shouldn't be the same. Instead, with AC adapter switched off, there should be a string like this: "current policy: frequency should be within 800 MHz and 800 MHz." (Showing only the lowest possible CPU frequency). Expected Results: It should be possible to use any of the physically available frequencies for current CPU in any case (with or without the AC adapter).
What "governor" are you using?
Please provide that information and reopen this bug report.
I use different CPU governors depending on the situation (for example, my cpufreqd daemon watches the temperature and switches from 'ondemand' governor to 'powersave' governor if the temperature is too high). When I turn off the AC adapter, it doesn't matter which governor I use - the highest available frequency is 800MHz. I tried to switch betweed different governors with AC adapter off - I can do that, but it just doesn't help.
What laptop are you using? I found this: If the battery pack is removed and the laptop is powered by AC only, the CPU downclocks to the lowest multiplier and remains locked in low speed. This happens irrespective of the scaling method in use (kernelspace or userspace) and of the frequency governor selected (ondemand, performance, etc.).
(In reply to comment #4) > What laptop are you using? > > I found this: > > If the battery pack is removed and the laptop is powered by AC only, the CPU > downclocks to the lowest multiplier and remains locked in low speed. This > happens irrespective of the scaling method in use (kernelspace or userspace) > and of the frequency governor selected (ondemand, performance, etc.). > I'm using MSI MegaBook S430X. My main concern is about the fact that it worked perfectly with 2.6.29 kernel.
Some news. Well, not actually news, but the results of a small investigation. Today I tested few different versions of gentoo-sources ( 2.6.29-gentoo-r6, 2.6.30-gentoo-r8, 2.6.30-gentoo-r9, 2.6.31-gentoo-r6, 2.6.32-gentoo-r13, 2.6.33-gentoo-r2, 2.6.34-gentoo-r3 and 2.6.35-gentoo). Looks like the 'bug appearance line' is between 2.6.29-gentoo-r6 and 2.6.30-gentoo-r8. In 2.6.29-gentoo-r6 kernel everything works fine if the following configure options are set to 'Y': CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K8_ACPI=y If I set one of these two to 'M' (build as a module), CPU will stick to the lowest possible frequency with AC turned off. Any of the 2.6.30+ kernels which I tested work regardlessly of these two settings - CPU sticks to the lowest frequency with AC adapter turned off. By the way, looks like in 2.6.30+ kernel there is no option named 'CONFIG_X86_POWERNOW_K8_ACPI'. Instead, there is an option named 'CONFIG_X86_POWERNOW_K8', but this is probably the same. I have also notices one interesting thing, which is present in 2.6.30+ kernels and is absent in 2.6.29 kernel. Namely, with the newer kernels when CPU temperature reaches ~84 C, something (I do not really know, what exactly) limits the highest available frequency to 800 MHz (the lowest physically available for my CPU), and after some seconds of work in such regime the temperature lowers and CPU switches to the 2,2 GHz back again. BUT! Sometimes, it doesn't switch back to high frequencies. Instead, it remains sticked to the lowest one (800 MHz) for an unlimited period of time, I guess. In such case unplugging and plugging back the AC adapter makes it work properly again (makes higher frequencies available again). With 2.6.29 kernel my CPU may be heated up to 90+ C degrees and nothing limits its frequency. By the way, my userspace programs can see the correct battery charge level and properly detect the AC adapter on/off transitions only with few recent kernels (and 2.6.29 is not one of them). Maybe, this is related somehow. I hope this information helps finding a solution. Regards, Vladimir.
Hello! I just wanted to report that with gentoo-2.6.36 kernel my laptop still works with the lowest available CPU frequency - 800MHz. But now the CPU temperature can increase any high (at least it seems so) with no frequency limitation around 85C. I must say that it is very inconvenient to work on the lowest available frequency. That is why it is very strange for me that there is no substantial interest to this problem among the developers. It looks like a serious but. Or maybe I'm wrong? Regards, Vladimir
Please post this upstream at http://bugzilla.kernel.org and post the link back here.
(In reply to comment #8) > Please post this upstream at http://bugzilla.kernel.org and post the link back > here. > Done. Here is a link: https://bugzilla.kernel.org/show_bug.cgi?id=23412
Watching upstream bug
