speedstep-centrino.ko fails to load after upgrade to kernel26 2.6.15.4-1

[Rubin]

Hi all,

I noticed that after upgrading to kernel26 2.6.15.4-1 earlier today,
that the speedstep-centrino.ko now fails to load on my ThinkPad T43:

[***@thinkpad ~]$ sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/
2.6.15-ARCH/kernel/arch/i386/kernel/cpu/cpufreq/
speedstep-centrino.ko): Device or resource busy

[***@thinkpad rubin]$ lsmod | grep speedstep
speedstep_lib 3844 0

It is obvious that speedstep-centrino is configured as a module, so what
happened? This problem did not occur under the previous version of the
kernel26 package.

As a side note, everything -seems- to be working normally, frequency
scaling works (I use the ondemand scheduler), no other weird things.


Kind regards,


Rubin.

[Greg Meyer]

Post by Rubin
I noticed that after upgrading to kernel26 2.6.15.4-1 earlier today,
   FATAL: Error inserting speedstep_centrino (/lib/modules/
   2.6.15-ARCH/kernel/arch/i386/kernel/cpu/cpufreq/
   speedstep-centrino.ko): Device or resource busy          
   speedstep_lib           3844  0
It is obvious that speedstep-centrino is configured as a module, so what
happened? This problem did not occur under the previous version of the
kernel26 package.

I confirm this error for me too, but since everything is working as expected,
I am going to assume the functionality of speedstep-centrino was preserved in
some other implementation.

[Jeff Mickey]

Confirmed here as well. No module gets loaded, but my cpu is down at
minimum frequency, not it's max. And it is dynamically switching
between.

The error lies in Dothan Centrino chips, but the kernel has added
support for them, I have a feeling it's not complete or as robust as
others.

// codemac

[Pete Morris]

Post by Jeff Mickey
Confirmed here as well. No module gets loaded, but my cpu is down at
minimum frequency, not it's max. And it is dynamically switching
between.
The error lies in Dothan Centrino chips, but the kernel has added
support for them, I have a feeling it's not complete or as robust as
others.
// codemac

I also saw this exact same thing after the upgrade, but I think it is a udev
issue, not a kernel one. Do a "lsmod | grep cpu". I had the acpi-cpufreq
module being loaded by udev prior to my loading the speedstep-centrino
module in my rc.conf modules array. Since one cpu frequency module is
already loaded, the "device or resource busy" error is thrown.

My system was less responsive with the acpi-cpufreq module - scrolling in vim
was jerky, for instance. Blacklisting all modules in
/lib/modules/2.6.15-ARCH/kernel/arch/i386/kernel/cpu/cpufreq except for the
speedstep-centrino module forces udev to load the correct module, but it
feels like a hack.

[Rubin]

Hi,

<snip>

..Blacklisting all modules in
/lib/modules/2.6.15-ARCH/kernel/arch/i386/kernel/cpu/cpufreq except for the
speedstep-centrino module forces udev to load the correct module, but it
feels like a hack.

<snip>

It is indeed a bit rigorous. I've found that only two modules need to be
disabled/blacklisted, like:


# Scan hardware and load required modules at bootup
MOD_AUTOLOAD="yes"

# Modules to load at boot-up (in this order)
MODULES=(!acpi-cpufreq !p4_clockmod speedstep-centrino realtime hci_usb
cdrom lp ppdev rtc i2c-i801 i2c-core evdev pcspkr serio_raw parport
parport_pc pci_hotplug shpchp crc-ccitt snd-mixer-oss snd-pcm-oss
snd-page-alloc snd-timer snd snd-ac97-bus snd-ac97-codec snd-intel8x0
soundcore generic ahci sd_mod sg sr_mod ata_piix libata irtty-sir
sir-dev ppp_generic slhc tg3 bluetooth ieee80211 ieee80211_crypt irda
ipw2200 pcmcia_core rsrc_nonstatic yenta_socket usb-storage usblp usbhid
usbcore ehci-hcd uhci-hcd nvram)


Notice the !acpi-cpufreq !p4_clockmod. Those are the disabled ones
(sounds like a Bowie song man)! With these two off, speedstep-centrino
loads without trouble on my T43.

Greets,

Rubin.

[Pete Morris]

Post by Rubin
Hi,
<snip>

..Blacklisting all modules in
/lib/modules/2.6.15-ARCH/kernel/arch/i386/kernel/cpu/cpufreq except for the
speedstep-centrino module forces udev to load the correct module, but it
feels like a hack.

<snip>
It is indeed a bit rigorous. I've found that only two modules need to be
# Scan hardware and load required modules at bootup
MOD_AUTOLOAD="yes"
# Modules to load at boot-up (in this order)
MODULES=(!acpi-cpufreq !p4_clockmod speedstep-centrino realtime hci_usb...

<snip>

Post by Rubin
Notice the !acpi-cpufreq !p4_clockmod. Those are the disabled ones
(sounds like a Bowie song man)! With these two off, speedstep-centrino
loads without trouble on my T43.

<snip>

Thanks for the tip! I can confirm that this works on my T40. I figured
that not all of the cpufreq modules needed to be blacklisted, I just hadn't
bothered to narrow down the list.

Pete

[Rafal Szczepaniak]

Post by Greg Meyer

Post by Rubin
It is obvious that speedstep-centrino is configured as a module, so what
happened? This problem did not occur under the previous version of the
kernel26 package.

I confirm this error for me too, but since everything is working as expected,
I am going to assume the functionality of speedstep-centrino was preserved in
some other implementation.

I had this too with my toshiba Pentium M notebook (i915).

The problem is that udev is loading wrong modules for the speedstepping.
You need to blacklist them in /etc/rc.conf and load centrino modules from
the MODULES.
Check out dmesg output for other modules that should be blacklisted because
udev tries to load (with no success) nforce and amd stuff too.

In my case IIRC it was (I don't have the notebook near me now so I can give you
the full list later if you want):
acpi-cpufreq
speedstep-ich (speedstep-lib was loaded as a dependency for this module)
cpufreq-nforce2
powernow-k7

After blacklisting these modules and loading centrino modules "manually" as
I did before upgrade everything worked fine.

The only unexplained thing in my dmesg output is now the message about
disabling irq 20 which is also displayed after udev during boot. I think it comes
from the usbcore module but I'm not sure what it is.
Everything seems to work fine though :-)