Distribution:Gentoo Hardware Environment: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 1 cpu MHz : 500.125 cache size : 256 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 mmx fxsr sse bogomips : 1000.68 Problem Description: Speedstep capability is not detected. However, I know that the hardware is capable of changing clock speeds because I can set it in BIOS. Also, suspending and then resuming with or without the AC attached changes clock frequency. Steps to reproduce: Attempts so far: Boot with cpufreq.debug=7 modprobe speedstep-lib relaxed_check=1 modprobe speedstep-smi, which gives "no such device". dmesg reports speedstep-lib: x86: 6, model: 8 speedstep-lib: Coppermine: MSR_IA32_EBL_CR_POWERON is 0x4c080020, 0x0 speedstep-lib: Coppermine: MSR_IA32_PLATFORM ID is 0x0, 0x540000 speedstep-lib: early PIII version speedstep-smi: signature:0x00008680, command:0x0000e6f5, event:0x00000000, perf_level:0x47534943. Looking at speedstep-smi.c, starting at line 379, there is a check /* Error if no IST-SMI BIOS or no PARM sig= 'ISGE' aka 'Intel Speedstep Gate E' */ if ((ist_info.signature != 0x47534943) && ( (smi_port == 0) || (smi_cmd == 0))) return -ENODEV; which is the one that fails, I guess. Anyway, what seems to happen is that the SIGNATURE (the field being tested) is not 0x47534943. However, perf_level does get that value - so, could it be that the CPU detection reads the values from wrong places? Could this be fixed with something as simple as an offset change with some CPUs?
Could you try with module options? modprobe speedstep-smi smi_port=0xb2 smi_cmd=0x82 smi_sig=1 Driver ignores a broken information and try to proceed. There are many reports that some coppermine platforms have odd bios. I think these platforms might be made before Intel/Microsoft defined the interface specification. In MS Windows, PC vendor can overwrite these parameters by setting the some registory values as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\HackFlags==0x5 or 0x1 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdPort==SMI Cmd Data Port HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\P3\Parameters\SmiCmdData==SMI Cmd Data Value You can find right values in pre-installed windows registory. These values may be set by Intel Speedstep Applet pre-installed or bandled. A registry location is defined in Microsoft's "Windows Native Processor Performance Control" document. The situation 'perf_level:0x47534943' is not an offset change. These values are retrived in arch/i386/boot/setup.S:507 movl $0x0000E980, %eax # IST Support movl $0x47534943, %edx #<-- # Request value int $0x15 movl %eax, (96) movl %ebx, (100) movl %ecx, (104) movl %edx, (108) #<-- so this means BIOS doesn't return a proper value on %edx, because of setting %edx as signature before call BIOS. Hiroshi Miura
With the suggested parameters, I get speedstep-lib: x86: 6, model: 8 speedstep-lib: Coppermine: MSR_IA32_EBL_CR_POWERON is 0x4c080020, 0x0 speedstep-lib: Coppermine: MSR_IA32_PLATFORM ID is 0x0, 0x540000 speedstep-lib: early PIII version speedstep-smi: signature:0x00008680, command:0x0000e6f5, event:0x00000000, perf_level:0x47534943. cpufreq-core: trying to register driver speedstep-smi cpufreq-core: adding CPU 0 speedstep-smi: trying to obtain ownership with command 47534982 at port b2 speedstep-smi: result is 0 speedstep-smi: bug #1422 -- can't read freqs from BIOS speedstep-smi: could not detect low and high frequencies by SMI call. speedstep-lib: trying to determine both speeds speedstep-lib: P3 - MSR_IA32_EBL_CR_POWERON: 0x4c080020 0x0 speedstep-lib: workaround for early PIIIs speedstep-lib: speed is 500000 speedstep-lib: previous speed is 500000 speedstep-smi: trying to set frequency to state 1 with command 47534982 at port b2 speedstep-smi: retry 1, previous result 0, waiting... speedstep-smi: retry 2, previous result 0, waiting... speedstep-smi: retry 3, previous result 0, waiting... speedstep-smi: retry 4, previous result 0, waiting... speedstep-smi: retry 5, previous result 0, waiting... cpufreq: change failed with new_state 2 and result 0 speedstep-lib: P3 - MSR_IA32_EBL_CR_POWERON: 0x4c080020 0x0 speedstep-lib: workaround for early PIIIs speedstep-lib: speed is 500000 speedstep-lib: low speed is 500000 speedstep-smi: trying to set frequency to state 0 with command 47534982 at port b2 speedstep-smi: retry 1, previous result 0, waiting... speedstep-smi: retry 2, previous result 0, waiting... speedstep-smi: retry 3, previous result 0, waiting... speedstep-smi: retry 4, previous result 0, waiting... speedstep-smi: retry 5, previous result 0, waiting... cpufreq: change failed with new_state 2 and result 0 speedstep-lib: P3 - MSR_IA32_EBL_CR_POWERON: 0x4c080020 0x0 speedstep-lib: workaround for early PIIIs speedstep-lib: speed is 500000 speedstep-lib: high speed is 500000 speedstep-smi: could not detect two different speeds -- aborting. cpufreq-core: initialization failed cpufreq-core: no CPU initialized for driver speedstep-smi cpufreq-core: unregistering CPU 0 The 500 MHz speed is correct, but that's about it. I don't have MS Windows available right now, but I'll try that out. Thanks for the tips.
Hmm, it seems that this old second-hand laptop does not support Speedstep after all - it's not mentioned in the specifications when I was able to dig them up. The BIOS can change processor speeds, (I can see it with /proc/cpuinfo), but it's not possible to control it from the OS.. Oh well. I didn't even know there were Coppermines that did not support Speedstep.