Bug 165494

cpufreq doesn't support >1 method at this time.

Making them non-modular simplifies a lot of probing details, so we can't just
make them modular without breaking existing setups.

I'm curious why speedstep isn't working with ondemand however.

It seems strange to me that you offer the alternatives as modules, but they
can't be loaded because of the one that is built in.
Is there a way to disable the built in one?

I found a web page of a gentoo user on a I8500 with the same problem.
http://wiki.archlinux.org/index.php/Dell_Inspiron_8500

Related:

On an Toshiba Satellite laying around me I really need to load acpi-cpufreq
because speedstep-ich does not work (I don't have anything in
/sys/devices/system/cpu/cpu0

So how can the acpi-cpufreq module be loaded if an alternative is compiled into
the kernel?

In terms of breaking existing setups, could you not have an additional boot
parameter to select which module to load, and default to speedstep if it is not
specified?

the fact that its compiled in should be irrelevant. if it can't work on your
hardware, it should return -ENODEV, and try the next driver until there are no
more built-ins to try. Then when we get to userspace, you should be able to load
acpi-cpufreq.

Your problem however seems to arise because speedstep-ich claims to support your
hardware, but in fact, doesn't.

Can you post the full dmesg, and lspci output please ?

Created attachment 119220 [details]
dmesg output

Created attachment 119221 [details]
lspci output

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

bug is still present in this kernel.

Created attachment 119747 [details]
output from lspci

Created attachment 119748 [details]
output from dmesg

Same problems since update to kernel 2.6.13-1.1526_FC4smp

  This is not limited to i686.  My father sees the "FATAL: Error inserting
acpi_cpufreq" message at boot time on an Emachines 300k which has an AMD K6-2
CPU, I think (I know it's an i586).

I get the "unable to load acpi-cpufreq module" on 2 of 3 machines I have
upgraded to 2.6.13-1.1532_FC4

Probably useless info but 3 are also fully updated all other RPMs:
No machine has been upgraded since initial install (full install 'everything')
with a few removals after install
I removed all cman* dlm* GFS* gnbd* RPM's before updating
(Also HAD to remove kde-i18n-Polish due to it conflicting with kdelibs)
Have a directory that is an image of all FC4 update RPMS and did a "rpm -Fvh
*.rpm" excluding the openssl 386 rpm

Then installed the updated kernel and rebooted

One is a Laptop: Dell Latitude C600 PIII 850MHz
2nd is a no-name (pre 2000 BIOS boot warning) PIII 933MHz desktop

3rd is a no-name Athlon 2400+ desktop (that doesn't give the error)

Obviously since the 3rd BIOS is OK and doesn't need to adjust the cpu speed it
doesn't get the error

Attachments to follow of boot message, dmesg & lspci for the Laptop

Created attachment 120770 [details]
laptop boot text

Created attachment 120771 [details]
laptop dmesg

Created attachment 120772 [details]
laptop lspci

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

Created attachment 120925 [details]
dmesg on 2.6.14-1.1637_FC4

2.6.14-1.1637_FC4 didn't fix the problem:

/sbin/modprobe acpi_cpufreq
FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.14-1.1637_FC4/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
Device or resource busy

--> dmesg

Created attachment 120926 [details]
lspci 2.6.14-1.1637_FC4

--> lspci

moved my info to bug #170979 (same message, same module, different cause)

Added DRIVER=p4-clockmod to /etc/cpuspeed.conf
has cured problem on my machine but is it right

VMAJOR=1
VMINOR=1

# uncomment this and set to the name of your CPUFreq module
#DRIVER="powernow-k7"
DRIVER="p4-clockmod"

# Let background (nice) processes speed up the cpu
OPTS="$OPTS -n"

# Add your favorite options here
#OPTS="$OPTS -s 0 -i 10 -r"

# uncomment and modify this to check the state of the AC adapter
#OPTS="$OPTS -a /proc/acpi/ac_adapter/*/state"

# uncomment and modify this to check the system temperature
OPTS="$OPTS -t /proc/acpi/thermal_zone/*/temperature 75"

I can confirm that the new kernel version does not work either.

CPUspeed will work as a userspace program to adjust CPU speed, but the point in
this report is to make the kernelspace code to do it.

Kernel 2.6.16-rc1 has some work by Mattia Dongili which fixes this issue for me. 
Can these fixes be backported to the current fedora kernels?

This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Hi, This is still a problem in the 2.6.15 kernel. As mentioned above, the fix is
in the 2.6.16 prepatches.

This could be related to bug 170979. 
 
As of tooday, the FATAL error is still present with  
[apodtele@somewhere ~]$ rpm -q kernel cpuspeed 
kernel-2.6.14-1.1656_FC4 
kernel-2.6.15-1.1831_FC4 
cpuspeed-1.2.1-1.24_FC4 
 

Bug 170979 seems to be that the acpi-cpufreq wont load because it can't find an
appropriate device. This bug is that it can't load because the speedstep module
claims it can handle the device (but can't) and so won't let the acpi-cpufreq
have control (it does however find the device)

can we get a kernel upgrade to 2.6.16 as it has been released to fix this problem?

[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.

The speedstep module was fixed in kernel 2.6.16 so this bug is no longer an
issue for me.