Bug 74589

Summary: speedstep doesn't work on IBM ThinkPad T30 (pentium 4)
Product: [Retired] Red Hat Public Beta Reporter: Pam Huntley <pam_huntley>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: nullCC: linux
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-17 09:22:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
cpuinfo
none
dmesg output while booting from ac power
none
output of dmesg while booting on battery power none

Description Pam Huntley 2002-09-27 03:58:44 UTC
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-27 03:59:23 UTC
Created attachment 77425 [details]
cpuinfo

Comment 2 Pam Huntley 2002-09-27 04:00:52 UTC
Created attachment 77426 [details]
dmesg output while booting from ac power

Comment 3 Pam Huntley 2002-09-27 04:01:25 UTC
Created attachment 77427 [details]
output of dmesg while booting on battery power

Comment 4 Dominik Brodowski 2002-09-27 07:52:38 UTC
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) {

to

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

re-compile, and it should work...


Comment 5 Arjan van de Ven 2002-10-17 09:22:44 UTC
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.

http://rhn.redhat.com/errata/RHSA-2002-206.html


Comment 6 Chris Runge 2002-11-18 16:05:45 UTC
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 18:32:52 UTC
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;

thx,
   Dominik

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