Description of problem: After an update to 2.6.17-1.2527.fc6 the following shows up in a startup: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.17-1.2527.fc6/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): Invalid argument The message comes from modprobe which is called by cpuspeed service. 'modprobe -v acpi_cpufreq' shows only that there is an attempt to run insmod before the message hits and strace shows that init_module(0x602030, 49224, "") = -1 EINVAL (Invalid argument) is unhappy while the required file exists. It is true that on that particular machine all this acpi_cpufreq was not ever doing anything useful but FATAL message is something new and it does not happen with earlier kernels. Version-Release number of selected component (if applicable): kernel-2.6.17-1.2527.fc6 How reproducible: always
No changes with 2.6.17-1.2530.fc6.
the modprobe acpi-cpufreq should only be done if grepping for est in /proc/cpuinfo returns true.
Created attachment 138607 [details] patch This patch should solve the problem.
actually, even better would be to check that it worked afterwards.. if [ -d /proc/acpi ]; then EST=`grep flags /proc/cpuinfo | grep est` if [ "$EST" ]; then # use ACPI as a fallback /sbin/modprobe acpi-cpufreq # even ACPI didn't work, remove it, and bail out. if [ -d /sys/devices/system/cpu/cpu0/cpufreq ]; then /sbin/rmmod acpi-cpufreq fi fi else Removing the module is important in cases where it fails, as leaving it around sometimes breaks suspend/resume for some bizarre reason.
Created attachment 140972 [details] proposed changes to init.d/cpuspeed This bug is still present in FC6 and on a machine defintely with ACPI but, apparently, lacking CPU scaling ability is causing the following on a startup: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.18-1.2798.fc6/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device and this if you will try 'service cpuspeed stop' cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver: No such file or directory It appears also that an attempt to run 'cpuspeed start' in a startup sequence make a console display, on an i386 laptop I got that, very "wobbly". Attached is another patch to prevent such misbehaviour.
Created attachment 140993 [details] new-and-improved cpuspeed.patch This script works now for me in a correct way. Changes also replace a misleading "for" loop with a code which hopefuly makes clear what is really going on. 'service cpuspeed stop' now also removes a driver module. If that is somewhat undesired, or if we really care if we succeeded for a lock removal, then one or two lines in 'stop' can be removed.
See also bug 215228 (cpuspeed configuration).
After an upgrade to F8 although 'modprobe acpi-cpufreq' still produces FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.23.8-63.fc8/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device but this is no longer issue as 'cpuspeed' service just does not start. After editing /etc/sysconfing/cpuspeed to carry over older working configuration with DRIVER="p4-clockmod", which used to work reasonably well, service 'cpuspeed' does start again but introduces such latencies, in order of many tenths of seconds or even minutes, that nobody could use that without assumptions that a machine already crashed. So the whole thing becomes unusable and the issue cannot show up again.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
AFICS with a "wrong" CPU 'modprobe acpi-cpufreq' is still producing: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.24.3-50.fc8/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device and some check, like that one proposed in comment #4, is NOT used. One is spared spamming by /etc/init.d/cpuspeed just because now the following is used there: '/sbin/modprobe acpi-cpufreq 2> /dev/null' so error messages are swallowed. If this is deemed to be a sufficient resolution then please close this bug. Hopefuly this "FATAL" will not have nasty side-effects in the future.
Yeah, the error message is a bit alarmist, but doesn't actually cause any problems anywhere that I've seen. The module fails to load because there's no supported hardware, and modprobe gets cranky. Easier to just mask out the spew, since we know its inconsequential in this case, than to screw around with the kernel and/or modprobe.