Pentium III (Coppermine) cpufreq support
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
The other two aren't making any noise about how this sucker's SpeedStep is supposed to work. Any suggestions?
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz), on a 440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP 0x0034, not 0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.
Are those in charge of the cpufreq development interested in getting the dump still, or have you moved on to bigger and better (tm) processors?
~Gibby
Hi all,
Another PIII(Speedstep)/440BZ owner chiming in...
I've been successful in getting the -smi driver to work (I believe). However, I need to apply this patch:
i386/kernel/cpu/cpufreq/speedstep-lib.c 2003-11-10 21:41:12.325084272 +0100 renamed from ../cf-2.6/cpufreq/linux/arch/i386/kernel/cpufreq/speedstep-lib.c 2003-08-19 15:38:33.000000000 +0200 +1 -1
@@ -200,7 +200,7 @@ */ rdmsr(MSR_IA32_PLATFORM_ID, msr_lo, msr_hi); dprintk(KERN_DEBUG "cpufreq: Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n", msr_lo, msr_hi); - if ((msr_hi & (1<<18)) && (msr_hi & (3<<24))) { + if ((msr_hi & (1<<18)) ) { if (c->x86_mask == 0x01) return SPEEDSTEP_PROCESSOR_PIII_C_EARLY; else
Now reading the comment just before these lines, it's apparent that this is not the way things are supposed to work. I've asked for this patch to be considered by the maintainers and the decision was not to apply it. I'd be interested in other approaches to getting past these lines in the cpu detection code which works can be committed.
You may want to check this path yourself. But I wouldn't be surprised if doing the Wrong Thing here could fry your box.
Question:
Is there any chance that tricking the code into accepting the cpu as speedstep-capable, would made the code appear to work when observing the behavior from outside but actually do no good to the metal? I don't have the hardware here to check if the box actually does consume less power when in low performance mode.
/Anders
Quoted 35 lines · Dominik Brodowski
In contrast to your opinion Linux cpufreq support for Mobile Pentium III=20 Coppermines on 440BX/ZX/DX has received an enormeous amount of work, especially from Bruno Ducrot and Hiroshi Miura. Also, one of the previous cpufreq maintainers (me) owns a notebook which contains a Mobile Pentium III Coppermine and a 440BX AGPset chipset...
Quoted 2 lines
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz)
There is no SpeedStep-capable mobile Pentium III with a core frequency of 4= 50 MHz.
The "lowest" SpeedStep-capable is a 500MHz variant. See Intel Document 245306, revision 43, page 14.However, it _might_ be that I miss something and this CPU is indeed speedstep capable.
Quoted 5 lines
, on a
440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP0x0034, not0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.There is no one which is _supposed_ to change. It's just that GPO #0 is the most _common_ to change. However, you really should try the speedstep-smi module first.
Quoted 2 lines
Are those in charge of the cpufreq development interested in getting the dump still, or have you moved on to bigger and better (tm) processors?
Even though I now own a wonderful centrino notebook, me and many others=20 still work on the various "earlier" speedstep drivers. So be a bit more=20 careful what you say, please.
Dominik
Quoted 2 lines · On Thu, Jan 29, 2004 at 12:16:00AM -0500, [email protected] wrote:
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
In contrast to your opinion Linux cpufreq support for Mobile Pentium III Coppermines on 440BX/ZX/DX has received an enormeous amount of work, especially from Bruno Ducrot and Hiroshi Miura. Also, one of the previous cpufreq maintainers (me) owns a notebook which contains a Mobile Pentium III Coppermine and a 440BX AGPset chipset...
Quoted 2 lines
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz)
There is no SpeedStep-capable mobile Pentium III with a core frequency of 450 MHz. The "lowest" SpeedStep-capable is a 500MHz variant. See Intel Document 245306, revision 43, page 14.
However, it _might_ be that I miss something and this CPU is indeed speedstep capable.
Quoted 5 lines
, on a
440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP0x0034, not0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.
There is no one which is _supposed_ to change. It's just that GPO #0 is the most _common_ to change. However, you really should try the speedstep-smi module first.
Quoted 2 lines
Are those in charge of the cpufreq development interested in getting the dump still, or have you moved on to bigger and better (tm) processors?
Even though I now own a wonderful centrino notebook, me and many others still work on the various "earlier" speedstep drivers. So be a bit more careful what you say, please.
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 10 lines
Quoted 3 lines
Now reading the comment just before these lines, it's apparent that this is not the way things are supposed to work.
Well, that the only 'official' info we got from Intel in order to detect a speedstep capable processor in earlier PIII coppermine... But they seems to be wrong (and actually some system do have an early speedstep-capable PIII coppermine that do not pass this check).
Sounds promising.
Quoted 8 lines
Quoted 7 lines
Question:
Is there any chance that tricking the code into accepting the cpu as speedstep-capable, would made the code appear to work when observing the behavior from outside but actually do no good to the metal? I don't have the hardware here to check if the box actually does consume less power when in low performance mode.
Quoted 4 lines
If you allow a non-speedstep capable processor, and if you use the speedstep-ich driver, this will likely freeze the system no matter what.
-ich. ? Do you mean -smi? That's the one I use...
Anyway, I guess I can conclude that i do have a speedstep capable box. If we can get feedback from others (e.g. visyz) indicating that this test may need to be relaxed/fixed/whatever a bit for different boxes, would a CONFIG_CPUFREQ_ANCIENT_SPEEDSTEP patch & option which captures that be adopted?
/Anders
Quoted 8 lines · Ducrot Bruno
Quoted 5 lines
Quoted 4 lines
If you allow a non-speedstep capable processor, and if you use the speedstep-ich driver, this will likely freeze the system no matter what.
-ich. ? Do you mean -smi? That's the one I use...
And? This code is shared with *all* speedstep drivers.
I know the detection code is shared. I assumed that the failure modes might be different for the different divers. I.e. a mis-detected cpu using the ich driver might cause a hang, while a mis-detected cpu on the -smi driver might cause a small fire, be undetected, whatever. Maybe that's a wromng assumption.
Quoted 8 lines
Quoted 5 lines
Anyway, I guess I can conclude that i do have a speedstep capable box. If we can get feedback from others (e.g. visyz) indicating that this test may need to be relaxed/fixed/whatever a bit for different boxes, would a
CONFIG_CPUFREQ_ANCIENT_SPEEDSTEPpatch & option which captures that be adopted?Make sense, but I know that such system already exist...
Not sure I follow here. Which system are you referring to?
/Anders
Quoted 5 lines · On Thu, Jan 29, 2004 at 12:16:00AM -0500, [email protected] wrote:
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
The other two aren't making any noise about how this sucker's SpeedStep is supposed to work. Any suggestions?
I receive more emails on this topics than 'two'...
Quoted 6 lines
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz), on a 440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP
0x0034, not0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.
What program? Mine? Also are you sure you looked in the web page. It's up to the manufacturer to *decide* what GPO to use. So there is *no* possibility to know the correct GPO pin.
Quoted 2 lines
Are those in charge of the cpufreq development interested in getting the dump still,
Yes, or else I would not publish it, you know. Just that this dump should be send to me privately, not in the cpufreq developper list.
Quoted 1 line
or have you moved on to bigger and better (tm) processors?
Actually, I never owned a laptop with a PIII coppermine with a 440BX/ZX/DX bridge FYI. I had a PIII coppermine, but with a ich southbridge.
Cheers,
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 7 lines · Dominik Brodowski
Quoted 2 lines · On Thu, Jan 29, 2004 at 12:16:00AM -0500, [email protected] wrote:
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
In contrast to your opinion Linux cpufreq support for Mobile Pentium III Coppermines on 440BX/ZX/DX has received an enormeous amount of work, especially from Bruno Ducrot and Hiroshi Miura. Also, one of the previous
Marc Lehmann gave a lot of his time to make people happy with SpeedStep and his userspace utility. I am not sure that speedstep-smi will born without his work.
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 20 lines · On Thu, Jan 29, 2004 at 09:50:36AM +0100, [email protected] wrote:
Hi all,
Another PIII(Speedstep)/440BZ owner chiming in...
I've been successful in getting the -smi driver to work (I believe). However, I need to apply this patch:
i386/kernel/cpu/cpufreq/speedstep-lib.c 2003-11-10 21:41:12.325084272 +0100 renamed from ../cf-2.6/cpufreq/linux/arch/i386/kernel/cpufreq/speedstep-lib.c 2003-08-19 15:38:33.000000000 +0200 +1
-1@@ -200,7 +200,7 @@ */ rdmsr(MSR_IA32_PLATFORM_ID, msr_lo, msr_hi); dprintk(KERN_DEBUG "cpufreq: Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n", msr_lo, msr_hi); - if ((msr_hi & (1<<18)) && (msr_hi & (3<<24))) { + if ((msr_hi & (1<<18)) ) { if (c->x86_mask == 0x01) return SPEEDSTEP_PROCESSOR_PIII_C_EARLY; else
Quoted 2 lines
Now reading the comment just before these lines, it's apparent that this is not the way things are supposed to work.
Well, that the only 'official' info we got from Intel in order to detect a speedstep capable processor in earlier PIII coppermine... But they seems to be wrong (and actually some system do have an early speedstep-capable PIII coppermine that do not pass this check).
Quoted 5 lines
I've asked for this patch to be considered by the maintainers and the decision was not to apply it. I'd be interested in other approaches to getting past these lines in the cpu detection code which works can be committed.
Quoted 9 lines
You may want to check this path yourself. But I wouldn't be surprised if doing the Wrong Thing here could fry your box. Question:
Is there any chance that tricking the code into accepting the cpu as speedstep-capable, would made the code appear to work when observing the behavior from outside but actually do no good to the metal? I don't have the hardware here to check if the box actually does consume less power when in low performance mode.
If you allow a non-speedstep capable processor, and if you use the speedstep-ich driver, this will likely freeze the system no matter what.
Cheers,
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 20 lines · On Thu, Jan 29, 2004 at 10:31:05AM +0100, [email protected] wrote:
Quoted 10 lines
Quoted 3 lines
Now reading the comment just before these lines, it's apparent that this is not the way things are supposed to work.
Well, that the only 'official' info we got from Intel in order to detect a speedstep capable processor in earlier PIII coppermine... But they seems to be wrong (and actually some system do have an early speedstep-capable PIII coppermine that do not pass this check).
Sounds promising.
Quoted 8 lines
Quoted 7 lines
Question:
Is there any chance that tricking the code into accepting the cpu as speedstep-capable, would made the code appear to work when observing the behavior from outside but actually do no good to the metal? I don't have the hardware here to check if the box actually does consume less power when in low performance mode.
Quoted 5 lines
Quoted 4 lines
If you allow a non-speedstep capable processor, and if you use the speedstep-ich driver, this will likely freeze the system no matter what.
-ich. ? Do you mean -smi? That's the one I use...
And? This code is shared with *all* speedstep drivers.
Quoted 5 lines
Anyway, I guess I can conclude that i do have a speedstep capable box. If we can get feedback from others (e.g. visyz) indicating that this test may need to be relaxed/fixed/whatever a bit for different boxes, would a
CONFIG_CPUFREQ_ANCIENT_SPEEDSTEPpatch & option which captures that be adopted?
Make sense, but I know that such system already exist...
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 9 lines · Ducrot Bruno
Quoted 8 lines
Quoted 2 lines
And? This code is shared with *all* speedstep drivers.
I know the detection code is shared. I assumed that the failure modes might be different for the different divers. I.e. a mis-detected cpu using the ich driver might cause a hang, while a mis-detected cpu on the -smi driver might cause a small fire, be undetected, whatever. Maybe that's a wromng assumption.
Quoted 4 lines
The fact that a mis-detected cpu in the ich case introduce a freeze of a system is enough to not include your patch in this form, no matter if it is safe (and I believe that it is the case) in the smi case.
OK. Right. I agree. Another solution is needed, then.
<snip>
Quoted 9 lines
Systems that support SMI call, but do not pass the speedstep capabilty check. There is even one that do not support the int15 check, that do not pass the speedstep capabitility check, but speedstep-smi driver work.
Therefore, there is no need to get feedback for this particular point, because it is already well known (at least by me) and I must admit that I should have fixed, and documented, this problem (my fault, my big fault, sorry)...
Fixed as in fixing code somewhere, or "just" document that it doesn't work (and perhaps never will)? If you have a plan for code mods to get this to work, please announce it and I/we can start hacking on it. I don't like having to patch the source for each upgrade...
Do we need more data points? I know my patch removes two bits from the test pattern. I have not checked if that's needed, or which bit is the offender. Should I check that, or is the culprit elsewhere?
/A
Quoted 7 lines · Anders Eriksson
Quoted 6 lines · Ducrot Bruno
Quoted 5 lines
Quoted 4 lines
If you allow a non-speedstep capable processor, and if you use the speedstep-ich driver, this will likely freeze the system no matter what.
-ich. ? Do you mean -smi? That's the one I use...
Quoted 8 lines
Quoted 2 lines
And? This code is shared with *all* speedstep drivers.
I know the detection code is shared. I assumed that the failure modes might be different for the different divers. I.e. a mis-detected cpu using the ich driver might cause a hang, while a mis-detected cpu on the -smi driver might cause a small fire, be undetected, whatever. Maybe that's a wromng assumption.
The fact that a mis-detected cpu in the ich case introduce a freeze of a system is enough to not include your patch in this form, no matter if it is safe (and I believe that it is the case) in the smi case.
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
Anyway, I guess I can conclude that i do have a speedstep capable box. If we can get feedback from others (e.g. visyz) indicating that this test may need to be relaxed/fixed/whatever a bit for different boxes, would a
CONFIG_CPUFREQ_ANCIENT_SPEEDSTEPpatch & option which captures that be adopted?Make sense, but I know that such system already exist...
Not sure I follow here. Which system are you referring to?
Systems that support SMI call, but do not pass the speedstep capabilty check. There is even one that do not support the int15 check, that do not pass the speedstep capabitility check, but speedstep-smi driver work.
Therefore, there is no need to get feedback for this particular point, because it is already well known (at least by me) and I must admit that I should have fixed, and documented, this problem (my fault, my big fault, sorry)...
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 28 lines · On Thu, Jan 29, 2004 at 02:18:19PM +0100, [email protected] wrote:
Quoted 9 lines · Ducrot Bruno
Quoted 8 lines
Quoted 2 lines
And? This code is shared with *all* speedstep drivers.
I know the detection code is shared. I assumed that the failure modes might be different for the different divers. I.e. a mis-detected cpu using the ich driver might cause a hang, while a mis-detected cpu on the -smi driver might cause a small fire, be undetected, whatever. Maybe that's a wromng assumption.
Quoted 4 lines
The fact that a mis-detected cpu in the ich case introduce a freeze of a system is enough to not include your patch in this form, no matter if it is safe (and I believe that it is the case) in the smi case.
OK. Right. I agree. Another solution is needed, then.
<snip>
Quoted 9 lines
Systems that support SMI call, but do not pass the speedstep capabilty check. There is even one that do not support the int15 check, that do not pass the speedstep capabitility check, but speedstep-smi driver work.
Therefore, there is no need to get feedback for this particular point, because it is already well known (at least by me) and I must admit that I should have fixed, and documented, this problem (my fault, my big fault, sorry)...
Quoted 8 lines
Fixed as in fixing code somewhere, or "just" document that it doesn't work (and perhaps never will)? If you have a plan for code mods to get this to work, please announce it and I/we can start hacking on it. I don't like having to patch the source for each upgrade...
Do we need more data points? I know my patch removes two bits from the test pattern. I have not checked if that's needed, or which bit is the offender. Should I check that, or is the culprit elsewhere?
Dominik have done some research in order to be sure that early coppermines are speedstep capable. I think he got the most possible bit in the check routines. So I'm afraid the only solution is to make a fix to release somehow the offending check via a kernel option (this may be usefull for speedstep-piix4 for example).
Documentation occur when adding stuff in Documentation/kernel-parameters.txt if you choose the kernel boot option and optionaly to add an howto in Documentation/cpu-freq/ for more detailed explanations.
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
From Ducrot Bruno on Thu, Jan 29, 2004 at 11:50:41AM +0100:
Quoted 5 lines · On Thu, Jan 29, 2004 at 12:16:00AM -0500, [email protected] wrote:
Quoted 2 lines
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
I receive more emails on this topics than 'two'...
Pardon the attitude. I was getting a bit angry at my laptop for not working with your speedstep systems. I didn't mean to come across quite like i did.
Quoted 10 lines
Quoted 6 lines
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz), on a 440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP
0x0034, not0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.What program? Mine? Also are you sure you looked in the web page. It's up to the manufacturer to *decide* what GPO to use. So there is *no* possibility to know the correct GPO pin.
The one available at http://www.poupinou.org/cpufreq/
and yes, while I was reading around the website, I got the impression that the dumped logs were /not/ to be emailed to you directly anymore.
At this point, I'm thinking I mixed up the various cpufreq pages I've been looking at.
If you're still interested in a fairly old laptop's speedstep, I'll follow the instructions on your page and send you the results later.
====
Again, I must apologize to you as a group. My manners were forgotten.
~Gibby
From Dominik Brodowski on Thu, Jan 29, 2004 at 10:26:04AM +0100:
Quoted 3 lines
There is no SpeedStep-capable mobile Pentium III with a core frequency of 450 MHz. The "lowest" SpeedStep-capable is a 500MHz variant. See Intel Document 245306, revision 43, page 14.
HP Omnibook model number f1662wt. I guarantee this thing peaks out at 450MHz (448.055, actually). GenuineIntel processor 0 family 6 model 8 stepping 1. Pentium III (Coppermine) with 256kb of cache.
While I'm not calling you a liar, I am saying that I'm not imagining it. This could be an HP 'special' where they took a 500 and ran it at 450. Or any other such thing. If it's not using SpeedStep, I'm not sure what it is using.
My current method of speed changing is to reboot the laptop with the AC plugged in for "high" mode, and unplugged for "low" mode. Once booted, it doesn't seem to change modes.
Quoted 3 lines
There is no one which is _supposed_ to change. It's just that GPO #0 is the most _common_ to change. However, you really should try the speedstep-smi module first.
I'll retry it a little later tonight, but as I recall, neither speedstep-smi nor speedstep-ich (which i tried just to see if it was me being stupid) worked, and complained about some very odd things.
Quoted 3 lines
Even though I now own a wonderful centrino notebook, me and many others still work on the various "earlier" speedstep drivers. So be a bit more careful what you say, please.
I apologize.
~Gibby
Quoted 10 lines · On Thu, Jan 29, 2004 at 03:28:24PM -0500, [email protected] wrote:
Quoted 6 lines
From Ducrot Bruno on Thu, Jan 29, 2004 at 11:50:41AM +0100:
Quoted 2 lines · On Thu, Jan 29, 2004 at 12:16:00AM -0500, [email protected] wrote:
So, I think I'm one of the 3 people in the world who have a Mobile Pentium III (Coppermine).
I receive more emails on this topics than 'two'...
Pardon the attitude. I was getting a bit angry at my laptop for not working with your speedstep systems. I didn't mean to come across quite like i did.
No problem. I was frustated as you some times ago. Fingers have their own live, typing some wordings without any more control. That happens to everyone, to me as well.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Heh. Yeah. anyways. I have an HP Omnibook 4150B, which amounts to the aforementioned coppermine (with speeds from 233-450mhz), on a 440BX/ZX/DX bridge. I tried out the test program to see if it's usable, and while 1 bit did change, it was in GOP
0x0034, not0x0038. Or maybe that's the other way around. Basically, the one that was supposed to change didn't, and the one that wasn't, did.
Quoted 7 lines
Quoted 3 lines
What program? Mine? Also are you sure you looked in the web page. It's up to the manufacturer to *decide* what GPO to use. So there is *no* possibility to know the correct GPO pin.
The one available at http://www.poupinou.org/cpufreq/
and yes, while I was reading around the website, I got the impression that the dumped logs were /not/ to be emailed to you directly anymore.
The speedstep-smi is much more safe than the speedstep-piix4, but unfortunately the former do not work for one or two persons, so the page about speedstep-piix4 is still here, and I have to maintain it somehow still. Note that speedstep-piix4 also may not work, there is no warranty, it work for some systems, not all. And I don't know why. Only Intel can say why.
That do not mean, though, that you can not send me the output of speedstep-detect, because this program may help you to configure speedstep-piix4 *and* speedstep-smi...
Quoted 5 lines
At this point, I'm thinking I mixed up the various cpufreq pages I've been looking at.
If you're still interested in a fairly old laptop's speedstep, I'll follow the instructions on your page and send you the results later.
Go on, I'm waiting your output,
Cheers,
Signature · 4 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care.