Bug 74589 - speedstep doesn't work on IBM ThinkPad T30 (pentium 4)
speedstep doesn't work on IBM ThinkPad T30 (pentium 4)
Product: Red Hat Public Beta
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-09-26 23:58 EDT by Pam Huntley
Modified: 2007-04-18 12:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-17 05:22:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cpuinfo (426 bytes, text/plain)
2002-09-26 23:59 EDT, Pam Huntley
no flags Details
dmesg output while booting from ac power (8.81 KB, text/plain)
2002-09-27 00:00 EDT, Pam Huntley
no flags Details
output of dmesg while booting on battery power (8.81 KB, text/plain)
2002-09-27 00:01 EDT, Pam Huntley
no flags Details

  None (edit)
Description Pam Huntley 2002-09-26 23:58:44 EDT
Description of Problem:
I get an error message when I try to modprobe speedstep on the IBM T30.  It has
a pentium 4 processor.  Here is the output of modprobe:
/lib/modules/2.4.18-11/kernel/arch/i386/kernel/speedstep.o: init_module:
Input/output error
Hint: insmod errors can be caused by incorrect module parameters, including
invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.18-11/kernel/arch/i386/kernel/speedstep.o: insmod
/lib/modules/2.4.18-11/kernel/arch/i386/kernel/speedstep.o failed
/lib/modules/2.4.18-11/kernel/arch/i386/kernel/speedstep.o: insmod speedstep failed

I'm also attaching /proc/cpuinfo, and the output of dmesg when booted on both ac
and battery power.

This is with the stock kernel from a (null) installation.
Comment 1 Pam Huntley 2002-09-26 23:59:23 EDT
Created attachment 77425 [details]
Comment 2 Pam Huntley 2002-09-27 00:00:52 EDT
Created attachment 77426 [details]
dmesg output while booting from ac power
Comment 3 Pam Huntley 2002-09-27 00:01:25 EDT
Created attachment 77427 [details]
output of dmesg while booting on battery power
Comment 4 Dominik Brodowski 2002-09-27 03:52:38 EDT
if you can re-compile the kernel, change line 413 of
linux/arch/i386/kernel/speedstep.c from

     if (msr_hi || ((msr_lo & 0x00FFFFFF) == 0x00300511) {


     if (msr_hi || ((msr_lo & 0x00FFF000) == 0x00300000) {

re-compile, and it should work...
Comment 5 Arjan van de Ven 2002-10-17 05:22:44 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

Comment 6 Chris Runge 2002-11-18 11:05:45 EST
I'm still seeing this problem on my T30 with the kernel-2.4.18-18.8.0 errata
applied. My T30 has a 2.0 GHz processor:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz
stepping        : 7
cpu MHz         : 1998.260
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3970.35

Comment 7 Dominik Brodowski 2003-01-09 13:32:52 EST
Intel seems to have produced a new stepping of P4-M - stepping 7. It's not in
their datasheets yet (as of December 2002), but I'm upgrading cpufreq now.
Arjan: somewhere in speedstep.c::speedstep_detect_processor you should find:

        if (c->x86 == 0xF) {
                /* Intel Pentium 4 Mobile P4-M */
                if (c->x86_model != 2)
                        return 0;

                if (c->x86_mask != 4)
                        return 0;

Please change the c->x86_mask check to:
                if ((c->x86_mask != 4) && (c->x86_mask != 7))
                        return 0;

Comment 8 Arjan van de Ven 2003-01-22 08:20:23 EST
done for next build/erratum; whenever that is

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