Bug 201463 - kernel 2.6.17-1.2527.fc6 induce FATAL message from modprobe
kernel 2.6.17-1.2527.fc6 induce FATAL message from modprobe
Product: Fedora
Classification: Fedora
Component: cpuspeed (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Depends On:
  Show dependency treegraph
Reported: 2006-08-05 16:17 EDT by Michal Jaegermann
Modified: 2008-08-02 19:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 21:51:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch (500 bytes, patch)
2006-10-16 14:41 EDT, Dave Jones
no flags Details | Diff
proposed changes to init.d/cpuspeed (1.74 KB, patch)
2006-11-11 17:04 EST, Michal Jaegermann
no flags Details | Diff
new-and-improved cpuspeed.patch (2.32 KB, patch)
2006-11-12 11:21 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2006-08-05 16:17:55 EDT
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
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):

How reproducible:
Comment 1 Michal Jaegermann 2006-08-08 15:28:40 EDT
No changes with 2.6.17-1.2530.fc6.
Comment 2 Dave Jones 2006-10-16 14:35:21 EDT
the modprobe acpi-cpufreq should only be done if grepping for est in
/proc/cpuinfo returns true.
Comment 3 Dave Jones 2006-10-16 14:41:58 EDT
Created attachment 138607 [details]

This patch should solve the problem.
Comment 4 Dave Jones 2006-10-16 14:45:56 EDT
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

Removing the module is important in cases where it fails, as leaving it around
sometimes breaks suspend/resume for some bizarre reason.
Comment 5 Michal Jaegermann 2006-11-11 17:04:15 EST
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
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

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.
Comment 6 Michal Jaegermann 2006-11-12 11:21:11 EST
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.
Comment 7 Michal Jaegermann 2006-11-12 11:42:29 EST
See also bug 215228 (cpuspeed configuration).
Comment 8 Michal Jaegermann 2007-12-10 20:44:13 EST
After an upgrade to F8 although 'modprobe acpi-cpufreq' still
FATAL: Error inserting acpi_cpufreq
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.
Comment 9 Bug Zapper 2008-04-03 23:27:20 EDT
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.

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:

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
Comment 10 Michal Jaegermann 2008-04-04 18:39:55 EDT
AFICS with a "wrong" CPU 'modprobe acpi-cpufreq' is still producing:

FATAL: Error inserting acpi_cpufreq
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.
Comment 11 Jarod Wilson 2008-04-04 21:51:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.