every time that I start gentoo with gentoo-sources-2.6.23/rc1 cpufreqd show follow message: cpufreqd requires the kernel to be configured with CONFIG_CPU_FREQ no problem with gentoo-sources-2.6.20-r8 Reproducible: Always
Same here - seems like cpufreqd is getting quite old without a recent update. BillK
i've update cpufreqd to 2.2.1 but no changes..... but if i make cat .config|grep CPU_FREQ of the kernel 2.6.23-r1 this is the result CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
I started having this problem after upgrading to gentoo-sources-2.6.23-r8 from gentoo-sources-2.6.22-r9. The init script (/etc/init.d/cpufreqd) itself is giving the error because it can't find either of /proc/cpufreq/ or /sys/devices/system/cpu/cpu0/cpufreq/. I think this might be related to some work apparently done to integrate the speedstep-centrino driver I used to use into the acpi-cpufreq driver. A modprobe acpi-cpufreq caused the files the init script to be created and cpufreqd appears to be happy now. So, for me at least the problem is resolved by putting acpi-cpufreq in /etc/modules.autoload.d/kernel-2.6. I'm curious though, isn't this something udev should be able to figure out and load for you automatically? Is it something like having the driver present with the default performance govenor cause issues on some systems so it needs to be manually enabled?
Confirmed here, adding acpi-cpufreq to autoload does the trick.
Looked into this a bit during today's bugday. I think the problem here is that the error message given by the init script did not indicate the true source of the problem. The most recent ebuilds have added the text "Make sure that the appropriate drivers for your CPU are available." This probably would have pointed me in the right direction. It might be a bit clearer to say "Make sure the appropriate drivers are built into your kernel or inserted as a module." Seems like this bug should be easy to close by either deciding the message is clear enough as it stands in the most recent version of the initscript or making it even more explicit along the lines of my suggestion above.
fixed in cvs. now the newer init script is also installed for 2.1.1. the real fix for this problem, however, is bug #152810 thanks for the report, the investigation into the problem and the suggested fix.