Bug 201463

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.