Bug 5985
| Summary: | speedstep-smi not detecting speedstep-capability with early Pentium 3 Coppermine | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Zarhan (zarhan) |
| Component: | cpufreq | Assignee: | cpufreq (cpufreq) |
| Status: | REJECTED DOCUMENTED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.15.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
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. |
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?