Pentium III (Coppermine) cpufreq support

Pentium III (Coppermine) cpufreq support

[visyz]

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

Re: Pentium III (Coppermine) cpufreq support

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 1715 bytes --]

On Thu, Jan 29, 2004 at 12:16:00AM -0500, visyz@visyz.net 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...

> 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.

>, 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.

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.

> 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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: Pentium III (Coppermine) cpufreq support

[aeriksson2]

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:

--- ../../cf-2.6/cpufreq/linux/arch/i386/kernel/cpufreq/speedstep-lib.c 2003-08-19 15:38:33.000000000 +0200
+++ arch/i386/kernel/cpu/cpufreq/speedstep-lib.c        2003-11-10 21:41:12.325084272 +0100
@@ -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


Dominik Brodowski <linux@dominikbrodowski.de> said:
> 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...
> 
> > 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.
> 
> >, 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.
> 
> 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.
> 
> > 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

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 09:50:36AM +0100, aeriksson2@fastmail.fm 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:
> 
> --- ../../cf-2.6/cpufreq/linux/arch/i386/kernel/cpufreq/speedstep-lib.c 2003-08-19 15:38:33.000000000 +0200
> +++ arch/i386/kernel/cpu/cpufreq/speedstep-lib.c        2003-11-10 21:41:12.325084272 +0100
> @@ -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.

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).

> 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.

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,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[aeriksson]

> > 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.

> > 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.
> 
-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

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 10:31:05AM +0100, aeriksson@fastmail.fm wrote:
> 
> > > 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.
> 
> > > 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.
> > 
> -ich. ? Do you mean -smi? That's the one I use...

And?  This code is shared with *all* speedstep drivers.

> 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?

Make sense, but I know that such system already exist...

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[Anders Eriksson]

Ducrot Bruno <ducrot@poupinou.org> said:
> > > 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.


> > 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?
> 
> Make sense, but I know that such system already exist...
> 
Not sure I follow here. Which system are you referring to?

/Anders

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 11:40:59AM +0100, Anders Eriksson wrote:
> Ducrot Bruno <ducrot@poupinou.org> said:
> > > > 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.

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.

> > > 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?
> > 
> > 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)...

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[aeriksson2]

Ducrot Bruno <ducrot@poupinou.org> said:
> > > 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.
> 
OK. Right. I agree. Another solution is needed, then.

<snip>
> 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

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 02:18:19PM +0100, aeriksson2@fastmail.fm wrote:
> 
> Ducrot Bruno <ducrot@poupinou.org> said:
> > > > 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.
> > 
> OK. Right. I agree. Another solution is needed, then.
> 
> <snip>
> > 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?

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.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 10:26:04AM +0100, Dominik Brodowski wrote:
> On Thu, Jan 29, 2004 at 12:16:00AM -0500, visyz@visyz.net 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.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[visyz]

From Dominik Brodowski on Thu, Jan 29, 2004 at 10:26:04AM +0100:
> 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.

> 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.

> 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

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 12:16:00AM -0500, visyz@visyz.net 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'...

> 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.

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.

> 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.

> 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,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Pentium III (Coppermine) cpufreq support

[visyz]

From Ducrot Bruno on Thu, Jan 29, 2004 at 11:50:41AM +0100:
> On Thu, Jan 29, 2004 at 12:16:00AM -0500, visyz@visyz.net 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.

> > 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.
> 
> 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

Re: Pentium III (Coppermine) cpufreq support

[Ducrot Bruno]

On Thu, Jan 29, 2004 at 03:28:24PM -0500, visyz@visyz.net wrote:
> >From Ducrot Bruno on Thu, Jan 29, 2004 at 11:50:41AM +0100:
> > On Thu, Jan 29, 2004 at 12:16:00AM -0500, visyz@visyz.net 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.

> > > 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.
> > 
> > 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...

> 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,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.