add new p3m model

add new p3m model

[Arjan van de Ven]

Hi,

the patch below adds support for my laptop (Dell Inspiron 2600) which has
ebx return 7 for the p3 mobile in it....

Greetings,
    Arjan van de Ven


--- linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c~	2004-03-07 15:31:51.305251000 +0100
+++ linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-07 15:31:51.305251000 +0100
@@ -265,10 +265,10 @@
 	case 0x0B: /* Intel PIII [Tualatin] */
 		/* cpuid_ebx(1) is 0x04 for desktop PIII, 
-		                   0x06 for mobile PIII-M */
+		                   0x06 and 0x07 for mobile PIII-M */
 		ebx = cpuid_ebx(0x00000001);
 
 		ebx &= 0x000000FF;
-		if (ebx != 0x06)
+		if ((ebx != 0x06) && (ebx != 0x07))
 			return 0;
 
 		/* So far all PIII-M processors support SpeedStep. See

Re: add new p3m model

[Arjan van de Ven]

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

On Mon, Mar 08, 2004 at 12:47:48PM +0100, Bas Mevissen wrote:
> Arjan van de Ven wrote:
> >Hi,
> >
> >the patch below adds support for my laptop (Dell Inspiron 2600) which has
> >ebx return 7 for the p3 mobile in it....
> >
> >Greetings,
> >    Arjan van de Ven
> >
> >
> >--- linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c~	2004-03-07 
> >15:31:51.305251000 +0100
> >+++ linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-07 
> >15:31:51.305251000 +0100
> >@@ -265,10 +265,10 @@
> > 	case 0x0B: /* Intel PIII [Tualatin] */
> > 		/* cpuid_ebx(1) is 0x04 for desktop PIII,
> >-		                   0x06 for mobile PIII-M */
> >+		                   0x06 and 0x07 for mobile PIII-M */
> 
> It is only text, but shouldn't that read "0x06 or 0x07"? It is one of 
> the two and not both values at the same time.

hehe probably.

> 
> BTW. Is this 0x07 also according specs or just what happens on the i2k6?

I have been unable to find a spec for this unfortionatly. Intel has this
like great confusing mess wrt finding docs 

[-- 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: add new p3m model

[Bas Mevissen]

Arjan van de Ven wrote:
> Hi,
> 
> the patch below adds support for my laptop (Dell Inspiron 2600) which has
> ebx return 7 for the p3 mobile in it....
> 
> Greetings,
>     Arjan van de Ven
> 
> 
> --- linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c~	2004-03-07 15:31:51.305251000 +0100
> +++ linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-07 15:31:51.305251000 +0100
> @@ -265,10 +265,10 @@
>  	case 0x0B: /* Intel PIII [Tualatin] */
>  		/* cpuid_ebx(1) is 0x04 for desktop PIII,
> -		                   0x06 for mobile PIII-M */
> +		                   0x06 and 0x07 for mobile PIII-M */

It is only text, but shouldn't that read "0x06 or 0x07"? It is one of 
the two and not both values at the same time.

BTW. Is this 0x07 also according specs or just what happens on the i2k6?

Bas.

Re: add new p3m model

[Bas Mevissen]

Arjan van de Ven wrote:

> 
>>BTW. Is this 0x07 also according specs or just what happens on the i2k6?
> 
> I have been unable to find a spec for this unfortionatly. Intel has this
> like great confusing mess wrt finding docs

OK, then I think this should be in the comment too. Now it looks like it 
is according spec and that is not sure at this time.

Regards,

Bas.

Re: add new p3m model

[Bruno Ducrot]

On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> Hi,
> 
> the patch below adds support for my laptop (Dell Inspiron 2600) which has
> ebx return 7 for the p3 mobile in it....
> 

Sorry, I checked documentations (AN, pentium III mobile specs updates at
dec. 2003, PIII specs update, etc.), but found nothing.
Since there is no processor that will return 7 for the brand id, I deduce
that your processor do not exist at all because Intel can not make
mistake, isn't it?

Hem, at least, since anyway that do not hurt the case for desktops or
servers PIII tualatins processors (hopefully, those should return
only 2 or 4, but who knows, after all), then I guess we can
accept your patch even if this processor do not exist.

Cheers,

-- 
Bruno Ducrot

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

Re: add new p3m model

[Dominik Brodowski]

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

On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> Hi,
> 
> the patch below adds support for my laptop (Dell Inspiron 2600) which has
> ebx return 7 for the p3 mobile in it....

Can you send a /proc/cpuinfo, please?

> --- linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c~	2004-03-07 15:31:51.305251000 +0100
> +++ linux-2.6.3/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-07 15:31:51.305251000 +0100
> @@ -265,10 +265,10 @@
>  	case 0x0B: /* Intel PIII [Tualatin] */
>  		/* cpuid_ebx(1) is 0x04 for desktop PIII, 
> -		                   0x06 for mobile PIII-M */
> +		                   0x06 and 0x07 for mobile PIII-M */

According to the latest Intel m-PIII-M doc I can find (24530643 of December
2003), 0x06 is the only valid ebx value. Might this be an engineering
sample? 

If we indeed add 0x07 as supported value here, we should at least make sure
we're "contrary to specification" here.

	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

speedstep capability checks

[aeriksson]

Hi, 

I'm one of the few who has a laptop (Dell L400) which doesn't announce
its speedstep capability to the OS the way is should. I made this
patch which turns my workaround into a compile time config option
which, if enabled, need to be explicitly enabled with a module
parameter. That should be non-invasive enough to allow it to be
included (I think).

Please have a look at the attached patch (against current cvs), and
indicate which improvements may be needed to allow it to be included.

/Anders


diff -u -b -B -w -p -r1.12 Kconfig
--- linux/arch/i386/kernel/cpufreq/Kconfig      20 Jan 2004 17:03:31 -0000      1.12
+++ linux/arch/i386/kernel/cpufreq/Kconfig      14 Mar 2004 15:11:37 -0000
@@ -163,6 +163,15 @@ config X86_SPEEDSTEP_LIB
        depends on (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD || X86_SPEEDSTEP_PII
X4)
        default (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD || X86_SPEEDSTEP_PIIX4)
 
+config X86_SPEEDSTEP_RELAXED_CAP_CHECK
+       bool "Relaxed speedstep capability checks"
+       depends on X86_SPEEDSTEP_LIB
+       help
+         Don't perform all checks for a speedstep capable system which would 
+         normally be done. Some ancient systems, though speedstep capable,
+         don't always indicate that they are speedstep capable. This option
+         let's the probing code bypass those checks.
+         
 config X86_P4_CLOCKMOD
        tristate "Intel Pentium 4 clock modulation"
        depends on CPU_FREQ_TABLE
diff -u -b -B -w -p -r1.3 speedstep-lib.c
--- linux/arch/i386/kernel/cpufreq/speedstep-lib.c      20 Jan 2004 17:03:31 -0000      1.3
+++ linux/arch/i386/kernel/cpufreq/speedstep-lib.c      14 Mar 2004 15:11:39 -0000
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h> 
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/cpufreq.h>
 #include <linux/pci.h>
@@ -30,6 +31,12 @@
 #define dprintk(msg...) do { } while(0)
 #endif
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+static int relaxed_check = 0;
+#else
+#define relaxed_check 0
+#endif
+
 /*********************************************************************
  *                   GET PROCESSOR CORE SPEED IN KHZ                 *
  *********************************************************************/
@@ -254,7 +261,7 @@ unsigned int speedstep_detect_processor 
                 */
                rdmsr(MSR_IA32_PLATFORM_ID, msr_lo, msr_hi);
                dprintk(KERN_DEBUG "cpufreq: Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n", ms
r_lo, msr_hi);
-               if ((msr_hi & (1<<18)) && (msr_hi & (3<<24))) {
+               if ((msr_hi & (1<<18)) && (relaxed_check ? 1 : (msr_hi & (3<<24)))) {
                        if (c->x86_mask == 0x01)
                                return SPEEDSTEP_PROCESSOR_PIII_C_EARLY;
                        else
@@ -323,6 +330,11 @@ unsigned int speedstep_get_freqs(unsigne
        return (ret);
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);
+
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+module_param(relaxed_check, int, 0444);
+MODULE_PARM_DESC(relaxed_check, "Don't do all checks for speedstep capability.");
+#endif
 
 MODULE_AUTHOR ("Dominik Brodowski <linux@brodo.de>");
 MODULE_DESCRIPTION ("Library for Intel SpeedStep 1 or 2 cpufreq drivers.");

Re: speedstep capability checks

[Dominik Brodowski]

I like this patch -- I've modified it a bit so that it applies to 2.6.4 and
also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 

Thanks,

	Dominik

On Sun, Mar 14, 2004 at 04:20:15PM +0100, aeriksson@fastmail.fm wrote:
> 
> Hi, 
> 
> I'm one of the few who has a laptop (Dell L400) which doesn't announce
> its speedstep capability to the OS the way is should. I made this
> patch which turns my workaround into a compile time config option
> which, if enabled, need to be explicitly enabled with a module
> parameter. That should be non-invasive enough to allow it to be
> included (I think).
> 
> Please have a look at the attached patch (against current cvs), and
> indicate which improvements may be needed to allow it to be included.
> 
> /Anders

A few SpeedStep-capable systems don't perform according to specification: the
CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
it definitely is. Allow a relaxed checking for two of these issues (Anders' and
Arjan's notebooks) by a module parameter only available if a config option is
turned on. This is done to avoid the risk of doing invalid speedstep instructions
on systems which do not support it, and which might even lead to (hardware) 
failure.

Patch originally from Andres Aeriksson (?) aeriksson at fastmail (dot) fm


diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig linux/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 13:44:04.186706640 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 14:20:56.278417584 +0100
@@ -176,6 +176,16 @@
 	depends on (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 	default (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 
+config X86_SPEEDSTEP_RELAXED_CAP_CHECK
+	bool "Relaxed speedstep capability checks"
+	depends on (X86_SPEEDSTEP_SMI || X86_SPEEDSTEP_ICH)
+	help
+	  Don't perform all checks for a speedstep capable system which would 
+	  normally be done. Some ancient or strange systems, though speedstep 
+	  capable, don't always indicate that they are speedstep capable. This 
+	  option let's the probing code bypass some of those checks if the
+	  parameter "relaxed_check=1" is passed to the module.
+
 config X86_LONGRUN
 	tristate "Transmeta LongRun"
 	depends on CPU_FREQ
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 09:20:50.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 14:15:46.835460064 +0100
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h> 
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/cpufreq.h>
 #include <linux/pci.h>
@@ -30,6 +31,12 @@
 #define dprintk(msg...) do { } while(0)
 #endif
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+static int relaxed_check = 0;
+#else
+#define relaxed_check 0
+#endif
+
 /*********************************************************************
  *                   GET PROCESSOR CORE SPEED IN KHZ                 *
  *********************************************************************/
@@ -265,6 +272,12 @@
 		ebx = cpuid_ebx(0x00000001);
 
 		ebx &= 0x000000FF;
+
+		/* Arjan reported a strange mobile PIII-M where ebx is
+		   0x07 */
+		if ((ebx == 0x07) && relaxed_check)
+			return SPEEDSTEP_PROCESSOR_PIII_T;
+
 		if (ebx != 0x06)
 			return 0;
 
@@ -292,7 +305,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)) && (relaxed_check ? 1 : (msr_hi & (3<<24)))) {
 			if (c->x86_mask == 0x01)
 				return SPEEDSTEP_PROCESSOR_PIII_C_EARLY;
 			else
@@ -362,6 +375,11 @@
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+module_param(relaxed_check, int, 0444);
+MODULE_PARM_DESC(relaxed_check, "Don't do all checks for speedstep capability.");
+#endif
+
 MODULE_AUTHOR ("Dominik Brodowski <linux@brodo.de>");
 MODULE_DESCRIPTION ("Library for Intel SpeedStep 1 or 2 cpufreq drivers.");
 MODULE_LICENSE ("GPL");

Re: speedstep capability checks

[Arjan van de Ven]

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


On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
> I like this patch -- I've modified it a bit so that it applies to 2.6.4 and
> also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 

Well I don't.
It's copping out by not autodetecting cases that can reasonably be
autodetected...

[-- 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: add new p3m model

[Arjan van de Ven]

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


On Sun, Mar 14, 2004 at 03:34:07PM +0100, Dominik Brodowski wrote:
> On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> > Hi,
> > 
> > the patch below adds support for my laptop (Dell Inspiron 2600) which has
> > ebx return 7 for the p3 mobile in it....
> 
> Can you send a /proc/cpuinfo, please?

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 11
model name	: Mobile Intel(R) Celeron(TM) CPU         1200MHz
stepping	: 4
cpu MHz		: 1196.449
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 mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips	: 2375.68


[-- 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: add new p3m model

[Dominik Brodowski]

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

On Mon, Mar 15, 2004 at 03:21:01PM +0100, Arjan van de Ven wrote:
> 
> On Sun, Mar 14, 2004 at 03:34:07PM +0100, Dominik Brodowski wrote:
> > On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> > > Hi,
> > > 
> > > the patch below adds support for my laptop (Dell Inspiron 2600) which has
> > > ebx return 7 for the p3 mobile in it....
> > 
> > Can you send a /proc/cpuinfo, please?
> 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 11
> model name	: Mobile Intel(R) Celeron(TM) CPU         1200MHz
                                  ^^^^^^^
so it's not a mobile Pentium III-M as you said before; but a Celeron. 
Celeron's don't support SpeedStep [*].

On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:
> 
> On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
> > I like this patch -- I've modified it a bit so that it applies to 2.6.4 and
> > also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 
> 
> Well I don't.
> It's copping out by not autodetecting cases that can reasonably be
> autodetected...

Well, as I stated in the description of this patch, it is _too risky_ to
enable SpeedStep on unsupported processors -- and we're talking hardware
failures here.

	Dominik

[*] And while some Celerons may work with certain speedstep drivers, it's so
much out-of-spec that I don't want to risk hardware failure in other cases
and enable speedstep support unconditionally on Centrinos, or even on
specific Centrino models.

[-- 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: add new p3m model

[Arjan van de Ven]

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

On Mon, Mar 15, 2004 at 03:38:27PM +0100, Dominik Brodowski wrote:
> On Mon, Mar 15, 2004 at 03:21:01PM +0100, Arjan van de Ven wrote:
> > 
> > On Sun, Mar 14, 2004 at 03:34:07PM +0100, Dominik Brodowski wrote:
> > > On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> > > > Hi,
> > > > 
> > > > the patch below adds support for my laptop (Dell Inspiron 2600) which has
> > > > ebx return 7 for the p3 mobile in it....
> > > 
> > > Can you send a /proc/cpuinfo, please?
> > 
> > processor	: 0
> > vendor_id	: GenuineIntel
> > cpu family	: 6
> > model		: 11
> > model name	: Mobile Intel(R) Celeron(TM) CPU         1200MHz
>                                   ^^^^^^^
> so it's not a mobile Pentium III-M as you said before; but a Celeron. 
> Celeron's don't support SpeedStep [*].

Hmmmm. Dell provides a windows driver for it..

[-- 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: speedstep capability checks

[Bruno Ducrot]

On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:
> 
> On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
> > I like this patch -- I've modified it a bit so that it applies to 2.6.4 and
> > also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 
> 
> Well I don't.
> It's copping out by not autodetecting cases that can reasonably be
> autodetected...

There were some speedstep capable processors (PIII 'early') that do not
pass the second check touched by this patch.

So far, the patch is ok for me.

Cheers,

-- 
Bruno Ducrot

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

Re: add new p3m model

[Bruno Ducrot]

On Mon, Mar 15, 2004 at 03:45:28PM +0100, Arjan van de Ven wrote:
> On Mon, Mar 15, 2004 at 03:38:27PM +0100, Dominik Brodowski wrote:
> > On Mon, Mar 15, 2004 at 03:21:01PM +0100, Arjan van de Ven wrote:
> > > 
> > > On Sun, Mar 14, 2004 at 03:34:07PM +0100, Dominik Brodowski wrote:
> > > > On Mon, Mar 08, 2004 at 12:15:31PM +0100, Arjan van de Ven wrote:
> > > > > Hi,
> > > > > 
> > > > > the patch below adds support for my laptop (Dell Inspiron 2600) which has
> > > > > ebx return 7 for the p3 mobile in it....
> > > > 
> > > > Can you send a /proc/cpuinfo, please?
> > > 
> > > processor	: 0
> > > vendor_id	: GenuineIntel
> > > cpu family	: 6
> > > model		: 11
> > > model name	: Mobile Intel(R) Celeron(TM) CPU         1200MHz
> >                                   ^^^^^^^
> > so it's not a mobile Pentium III-M as you said before; but a Celeron. 
> > Celeron's don't support SpeedStep [*].
> 
> Hmmmm. Dell provides a windows driver for it..

Are you sure that it's a speedstep driver?  I've seen a toshiba blurb
claiming Speedstep with 8 states on a PIII.  It was actually throttling
of course, not speedstep..

Cheers,

-- 
Bruno Ducrot

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

Re: add new p3m model

[Dave Jones]

On Mon, Mar 15, 2004 at 04:46:39PM +0100, Bruno Ducrot wrote:

 > > > > model name	: Mobile Intel(R) Celeron(TM) CPU         1200MHz
 > > >                                   ^^^^^^^
 > > > so it's not a mobile Pentium III-M as you said before; but a Celeron. 
 > > > Celeron's don't support SpeedStep [*].
 > > 
 > > Hmmmm. Dell provides a windows driver for it..
 > 
 > Are you sure that it's a speedstep driver?  I've seen a toshiba blurb
 > claiming Speedstep with 8 states on a PIII.  It was actually throttling
 > of course, not speedstep..

(from memory) looking through the specupdate's not that long ago, I don't
recall seeing a single Celeron mentioned there with Speedstep capability.
Could be I overlooked something though.

		Dave

Re: speedstep capability checks

[Bruno Ducrot]

On Sun, Mar 14, 2004 at 04:20:15PM +0100, aeriksson@fastmail.fm wrote:
> 
> Please have a look at the attached patch (against current cvs), and
> indicate which improvements may be needed to allow it to be included.

Note that current CVS is not well maintained for sending patches by now,
with the only exception for tag LINUX_2_4, due mostly to me not maintaining
enough the cvs repo I guess.

It may be better to send patches against current cpufreq bk tree instead for
all 2.6 stuff: bk://linux-dj.bkbits.net/cpufreq

For 2.4 related patches, please use cvs, tag LINUX_2_4.


Thanks,

-- 
Bruno Ducrot

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

Re: speedstep capability checks

[aeriksson]

> It may be better to send patches against current cpufreq bk tree instead for
> all 2.6 stuff: bk://linux-dj.bkbits.net/cpufreq
> 

Haven't played with bk, yet. Is bk://linux-dj.bkbits.net/cpufreq reachable with the bk2cvs thing?

Re: speedstep capability checks

[aeriksson]

ducrot@poupinou.org said:
> On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:
> 
> On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
> > I like this patch -- I've modified it a bit so that it applies to
> 2.6.4 and
> > also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 
> 
> Well I don't.
> It's copping out by not autodetecting cases that can reasonably be
> autodetected...
>
> There were some speedstep capable processors (PIII 'early') that do
> not pass the second check touched by this patch.
>
> So far, the patch is ok for me.

Cool!

I'd be happy to see it make its way into the kernel. If there was a
way to auto detect this, I'd of course prefer that. But I don't know
of any...

Cheers,

/Anders Eriksson

Re: speedstep capability checks

[Bruno Ducrot]

On Mon, Mar 15, 2004 at 08:25:28PM +0100, aeriksson@fastmail.fm wrote:
> 
> I'd be happy to see it make its way into the kernel. If there was a
> way to auto detect this, I'd of course prefer that. But I don't know
> of any...
> 

It's up to Dave to decide.  I can only say if that's OK for me, or not.
Actually, the Arjan part seems to be not acceptable unfortunately.

-- 
Bruno Ducrot

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

Re: speedstep capability checks

[Bruno Ducrot]

On Mon, Mar 15, 2004 at 08:20:43PM +0100, aeriksson@fastmail.fm wrote:
> 
> > It may be better to send patches against current cpufreq bk tree instead for
> > all 2.6 stuff: bk://linux-dj.bkbits.net/cpufreq
> > 
> 
> Haven't played with bk, yet. Is bk://linux-dj.bkbits.net/cpufreq reachable with the bk2cvs thing?
> 

Don't know.  The dj means Dave John, in case you didn't know.

-- 
Bruno Ducrot

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

Re: speedstep capability checks

[Arjan van de Ven]

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


On Mon, Mar 15, 2004 at 08:35:56PM +0100, Bruno Ducrot wrote:
> On Mon, Mar 15, 2004 at 08:25:28PM +0100, aeriksson@fastmail.fm wrote:
> > 
> > I'd be happy to see it make its way into the kernel. If there was a
> > way to auto detect this, I'd of course prefer that. But I don't know
> > of any...
> > 
> 
> It's up to Dave to decide.  I can only say if that's OK for me, or not.
> Actually, the Arjan part seems to be not acceptable unfortunately.

Just for the record: I have absolutely no problem with my bits not going in
based on the comments in this thread ;)




[-- 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: speedstep capability checks

[Dominik Brodowski]

On Mon, Mar 15, 2004 at 08:20:43PM +0100, aeriksson@fastmail.fm wrote:
> 
> > It may be better to send patches against current cpufreq bk tree instead for
> > all 2.6 stuff: bk://linux-dj.bkbits.net/cpufreq
> > 
> 
> Haven't played with bk, yet. Is bk://linux-dj.bkbits.net/cpufreq reachable with the bk2cvs thing?

Usually it should be enough to use the latest plain kernel source from
www.kernel.org, and to send patches then.

	Dominik

[updated patch] Re: speedstep capability checks

[Dominik Brodowski]

On Mon, Mar 15, 2004 at 08:25:28PM +0100, aeriksson@fastmail.fm wrote:
> 
> ducrot@poupinou.org said:
> > On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:
> > 
> > On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
> > > I like this patch -- I've modified it a bit so that it applies to
> > 2.6.4 and
> > > also handles Arjan's strange 0x07 Tualatin. Please apply, Dave. 
> > 
> > Well I don't.
> > It's copping out by not autodetecting cases that can reasonably be
> > autodetected...
> >
> > There were some speedstep capable processors (PIII 'early') that do
> > not pass the second check touched by this patch.
> >
> > So far, the patch is ok for me.
> 
> Cool!
> 
> I'd be happy to see it make its way into the kernel. If there was a
> way to auto detect this, I'd of course prefer that. But I don't know
> of any...

... and I don't want to take any risks. Here's an updated version of the
patch which applies cleanly to 2.6.4 -- and which does no longer contain the
wrong workaround for the Celeron Arjan talked about.



A few SpeedStep-capable systems don't perform according to specification: the
CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
it definitely is. Allow a relaxed checking for one such issue by a module 
parameter only available if a config option is turned on. This is done to 
avoid the risk of doing invalid speedstep instructions on systems which do 
not support it, and which might even lead to (hardware) failure.

Patch originally from Anders Eriksson, aeriksson at fastmail (dot) fm

 arch/i386/kernel/cpu/cpufreq/Kconfig         |   10 ++++++++++
 arch/i386/kernel/cpu/cpufreq/speedstep-lib.c |   15 ++++++++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig linux/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 20:39:02.713752552 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 19:50:16.000000000 +0100
@@ -176,6 +176,16 @@
 	depends on (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 	default (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 
+config X86_SPEEDSTEP_RELAXED_CAP_CHECK
+	bool "Relaxed speedstep capability checks"
+	depends on (X86_SPEEDSTEP_SMI || X86_SPEEDSTEP_ICH)
+	help
+	  Don't perform all checks for a speedstep capable system which would 
+	  normally be done. Some ancient or strange systems, though speedstep 
+	  capable, don't always indicate that they are speedstep capable. This 
+	  option let's the probing code bypass some of those checks if the
+	  parameter "relaxed_check=1" is passed to the module.
+
 config X86_LONGRUN
 	tristate "Transmeta LongRun"
 	depends on CPU_FREQ
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 20:39:02.737748904 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 20:39:41.176905264 +0100
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h> 
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/cpufreq.h>
 #include <linux/pci.h>
@@ -30,6 +31,12 @@
 #define dprintk(msg...) do { } while(0)
 #endif
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+static int relaxed_check = 0;
+#else
+#define relaxed_check 0
+#endif
+
 /*********************************************************************
  *                   GET PROCESSOR CORE SPEED IN KHZ                 *
  *********************************************************************/
@@ -265,6 +272,7 @@
 		ebx = cpuid_ebx(0x00000001);
 
 		ebx &= 0x000000FF;
+
 		if (ebx != 0x06)
 			return 0;
 
@@ -292,7 +300,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)) && (relaxed_check ? 1 : (msr_hi & (3<<24)))) {
 			if (c->x86_mask == 0x01)
 				return SPEEDSTEP_PROCESSOR_PIII_C_EARLY;
 			else
@@ -362,6 +370,11 @@
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+module_param(relaxed_check, int, 0444);
+MODULE_PARM_DESC(relaxed_check, "Don't do all checks for speedstep capability.");
+#endif
+
 MODULE_AUTHOR ("Dominik Brodowski <linux@brodo.de>");
 MODULE_DESCRIPTION ("Library for Intel SpeedStep 1 or 2 cpufreq drivers.");
 MODULE_LICENSE ("GPL");

Re: speedstep capability checks

[Dave Jones]

On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
 > @@ -265,6 +272,12 @@
 >  		ebx = cpuid_ebx(0x00000001);
 >  
 >  		ebx &= 0x000000FF;
 > +
 > +		/* Arjan reported a strange mobile PIII-M where ebx is
 > +		   0x07 */
 > +		if ((ebx == 0x07) && relaxed_check)
 > +			return SPEEDSTEP_PROCESSOR_PIII_T;
 > +
 >  		if (ebx != 0x06)
 >  			return 0;

Any reason we can't just check the ebx==0x07, guarded with appropriate
checks on model/stepping/brand ? The relaxed_check stuff does seem quite ugly to me.

		Dave

Re: speedstep capability checks

[Dominik Brodowski]

On Mon, Mar 15, 2004 at 09:09:50PM +0000, Dave Jones wrote:
> On Mon, Mar 15, 2004 at 03:15:17PM +0100, Dominik Brodowski wrote:
>  > @@ -265,6 +272,12 @@
>  >  		ebx = cpuid_ebx(0x00000001);
>  >  
>  >  		ebx &= 0x000000FF;
>  > +
>  > +		/* Arjan reported a strange mobile PIII-M where ebx is
>  > +		   0x07 */
>  > +		if ((ebx == 0x07) && relaxed_check)
>  > +			return SPEEDSTEP_PROCESSOR_PIII_T;
>  > +
>  >  		if (ebx != 0x06)
>  >  			return 0;
> 
> Any reason we can't just check the ebx==0x07, guarded with appropriate
> checks on model/stepping/brand ? The relaxed_check stuff does seem quite ugly to me.

First of all, this hunk isn't there in the last revision of the patch [also
attached here for your convenience] as this was a workaround which falsely
enabled SpeedStep on a Celeron, and running SpeedStep on Celerons might
cause hardware damage.

For the other "relaxed_check": An Intel document says that all 
SpeedStep-capable Coppermines succeed the check, and all 
non-SpeedStep-capable Coppermines fail the check -- see
http://www.intel.com/support/processors/sb/cs-003779-prd24.htm

So, Anders' CPU reports itself to be non-SpeedStep-capable. However,
SpeedStep runs fine on his CPU. We can't enable SpeedStep on all CPUs [even
of the same stepping (model/brand are the same anyway)] as we don't know if
all of them work fine if running SpeedStep on them -- or if it causes
(permanent) hardware failure! Some, who know it works from running a
different OS, and possibly a specific vendor-provided driver on their
notebook, might want to skip this test and try out their luck. But then they
know what they're doing, and that they're risking their own hardware.

	Dominik

A few SpeedStep-capable systems don't perform according to specification: the
CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
it definitely is. Allow a relaxed checking for one such issue by a module 
parameter only available if a config option is turned on. This is done to 
avoid the risk of doing invalid speedstep instructions on systems which do 
not support it, and which might even lead to (hardware) failure.

Patch originally from Anders Eriksson - aeriksson at fastmail (dot) fm

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig linux/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-original/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 20:39:02.713752552 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig	2004-03-15 19:50:16.000000000 +0100
@@ -176,6 +176,16 @@
 	depends on (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 	default (X86_SPEEDSTEP_ICH || X86_SPEEDSTEP_SMI || X86_P4_CLOCKMOD)
 
+config X86_SPEEDSTEP_RELAXED_CAP_CHECK
+	bool "Relaxed speedstep capability checks"
+	depends on (X86_SPEEDSTEP_SMI || X86_SPEEDSTEP_ICH)
+	help
+	  Don't perform all checks for a speedstep capable system which would 
+	  normally be done. Some ancient or strange systems, though speedstep 
+	  capable, don't always indicate that they are speedstep capable. This 
+	  option let's the probing code bypass some of those checks if the
+	  parameter "relaxed_check=1" is passed to the module.
+
 config X86_LONGRUN
 	tristate "Transmeta LongRun"
 	depends on CPU_FREQ
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 20:39:02.737748904 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-lib.c	2004-03-15 20:39:41.176905264 +0100
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/module.h> 
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/cpufreq.h>
 #include <linux/pci.h>
@@ -30,6 +31,12 @@
 #define dprintk(msg...) do { } while(0)
 #endif
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+static int relaxed_check = 0;
+#else
+#define relaxed_check 0
+#endif
+
 /*********************************************************************
  *                   GET PROCESSOR CORE SPEED IN KHZ                 *
  *********************************************************************/
@@ -265,6 +272,7 @@
 		ebx = cpuid_ebx(0x00000001);
 
 		ebx &= 0x000000FF;
+
 		if (ebx != 0x06)
 			return 0;
 
@@ -292,7 +300,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)) && (relaxed_check ? 1 : (msr_hi & (3<<24)))) {
 			if (c->x86_mask == 0x01)
 				return SPEEDSTEP_PROCESSOR_PIII_C_EARLY;
 			else
@@ -362,6 +370,11 @@
 }
 EXPORT_SYMBOL_GPL(speedstep_get_freqs);
 
+#ifdef CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK
+module_param(relaxed_check, int, 0444);
+MODULE_PARM_DESC(relaxed_check, "Don't do all checks for speedstep capability.");
+#endif
+
 MODULE_AUTHOR ("Dominik Brodowski <linux@brodo.de>");
 MODULE_DESCRIPTION ("Library for Intel SpeedStep 1 or 2 cpufreq drivers.");
 MODULE_LICENSE ("GPL");

Re: speedstep capability checks

[Dave Jones]

On Tue, Mar 16, 2004 at 08:38:47AM +0100, Dominik Brodowski wrote:

 > So, Anders' CPU reports itself to be non-SpeedStep-capable. However,
 > SpeedStep runs fine on his CPU. We can't enable SpeedStep on all CPUs [even
 > of the same stepping (model/brand are the same anyway)] as we don't know if
 > all of them work fine if running SpeedStep on them -- or if it causes
 > (permanent) hardware failure! Some, who know it works from running a
 > different OS, and possibly a specific vendor-provided driver on their
 > notebook, might want to skip this test and try out their luck. But then they
 > know what they're doing, and that they're risking their own hardware.

We've already seen quite a few confused users who thought that throttling == speedstep.
This sounds like handing someone a gun and saying 'point it at your head,
pull the trigger, it might miss'.

 > A few SpeedStep-capable systems don't perform according to specification: the
 > CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
 > it definitely is.

Is there nothing in the errata documents about this ?

 > Allow a relaxed checking for one such issue by a module 
 > parameter only available if a config option is turned on. This is done to 
 > avoid the risk of doing invalid speedstep instructions on systems which do 
 > not support it, and which might even lead to (hardware) failure.

I'd merge this really as a last resort, and it's beginning to sound like
we don't really have any options (other than not support those broken boxes). Ugh.

		Dave

Re: speedstep capability checks

[Bruno Ducrot]

On Tue, Mar 16, 2004 at 01:01:14PM +0000, Dave Jones wrote:
> On Tue, Mar 16, 2004 at 08:38:47AM +0100, Dominik Brodowski wrote:
> 
>  > So, Anders' CPU reports itself to be non-SpeedStep-capable. However,
>  > SpeedStep runs fine on his CPU. We can't enable SpeedStep on all CPUs [even
>  > of the same stepping (model/brand are the same anyway)] as we don't know if
>  > all of them work fine if running SpeedStep on them -- or if it causes
>  > (permanent) hardware failure! Some, who know it works from running a
>  > different OS, and possibly a specific vendor-provided driver on their
>  > notebook, might want to skip this test and try out their luck. But then they
>  > know what they're doing, and that they're risking their own hardware.
> 
> We've already seen quite a few confused users who thought that throttling == speedstep.
> This sounds like handing someone a gun and saying 'point it at your head,
> pull the trigger, it might miss'.
> 
>  > A few SpeedStep-capable systems don't perform according to specification: the
>  > CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
>  > it definitely is.
> 
> Is there nothing in the errata documents about this ?

There is nothing in any data sheets for the check anyway, other than
it's not possible to distinguish a PIII (coppermine) with Speedstep
technology from one without Speedstep technology.  There is nothing
in any spec update I'm aware.

There is only one solution from technical support from intel at
http://www.intel.com/support/processors/cs-003779-prd24.html and I'm not
sure how to get that page other than by searching it via the search
functionality of intel site.

-- 
Bruno Ducrot

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

Re: speedstep capability checks

[Dominik Brodowski]

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

On Tue, Mar 16, 2004 at 04:01:48PM +0100, Bruno Ducrot wrote:
> On Tue, Mar 16, 2004 at 01:01:14PM +0000, Dave Jones wrote:
> > On Tue, Mar 16, 2004 at 08:38:47AM +0100, Dominik Brodowski wrote:
> > 
> >  > So, Anders' CPU reports itself to be non-SpeedStep-capable. However,
> >  > SpeedStep runs fine on his CPU. We can't enable SpeedStep on all CPUs [even
> >  > of the same stepping (model/brand are the same anyway)] as we don't know if
> >  > all of them work fine if running SpeedStep on them -- or if it causes
> >  > (permanent) hardware failure! Some, who know it works from running a
> >  > different OS, and possibly a specific vendor-provided driver on their
> >  > notebook, might want to skip this test and try out their luck. But then they
> >  > know what they're doing, and that they're risking their own hardware.
> > 
> > We've already seen quite a few confused users who thought that throttling == speedstep.
> > This sounds like handing someone a gun and saying 'point it at your head,
> > pull the trigger, it might miss'.
> > 
> >  > A few SpeedStep-capable systems don't perform according to specification: the
> >  > CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
> >  > it definitely is.
> > 
> > Is there nothing in the errata documents about this ?
> 
> There is nothing in any data sheets for the check anyway, other than
> it's not possible to distinguish a PIII (coppermine) with Speedstep
> technology from one without Speedstep technology.  There is nothing
> in any spec update I'm aware.
> 
> There is only one solution from technical support from intel at
> http://www.intel.com/support/processors/cs-003779-prd24.html

This should read

http://www.intel.com/support/processors/sb/cs-003779-prd24.htm

AFAIK.

	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: speedstep capability checks

[Dominik Brodowski]

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

On Tue, Mar 16, 2004 at 01:01:14PM +0000, Dave Jones wrote:
> On Tue, Mar 16, 2004 at 08:38:47AM +0100, Dominik Brodowski wrote:
> 
>  > So, Anders' CPU reports itself to be non-SpeedStep-capable. However,
>  > SpeedStep runs fine on his CPU. We can't enable SpeedStep on all CPUs [even
>  > of the same stepping (model/brand are the same anyway)] as we don't know if
>  > all of them work fine if running SpeedStep on them -- or if it causes
>  > (permanent) hardware failure! Some, who know it works from running a
>  > different OS, and possibly a specific vendor-provided driver on their
>  > notebook, might want to skip this test and try out their luck. But then they
>  > know what they're doing, and that they're risking their own hardware.
> 
> We've already seen quite a few confused users who thought that throttling == speedstep.
> This sounds like handing someone a gun and saying 'point it at your head,
> pull the trigger, it might miss'.

Maybe the help text should be clarified a bit?

>  > A few SpeedStep-capable systems don't perform according to specification: the
>  > CPUID and/or some MSRs don't tell us the CPU is SpeedStep capable even though
>  > it definitely is.
> 
> Is there nothing in the errata documents about this ?

Unfortunately, no AFAIK.

>  > Allow a relaxed checking for one such issue by a module 
>  > parameter only available if a config option is turned on. This is done to 
>  > avoid the risk of doing invalid speedstep instructions on systems which do 
>  > not support it, and which might even lead to (hardware) failure.
> 
> I'd merge this really as a last resort, and it's beginning to sound like
> we don't really have any options (other than not support those broken boxes). Ugh.

I'd much prefer if the check posted on Intel's website were accurate, too,
and wouldn't have false negatives. (I doubt it has false positives).

	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: speedstep capability checks

[Bruno Ducrot]

> >  > Allow a relaxed checking for one such issue by a module 
> >  > parameter only available if a config option is turned on. This is done to 
> >  > avoid the risk of doing invalid speedstep instructions on systems which do 
> >  > not support it, and which might even lead to (hardware) failure.
> > 
> > I'd merge this really as a last resort, and it's beginning to sound like
> > we don't really have any options (other than not support those broken boxes). Ugh.
> 
> I'd much prefer if the check posted on Intel's website were accurate, too,
> and wouldn't have false negatives. (I doubt it has false positives).

By now, I have seen only one real false positive and it was for
speedstep-smi.

Now that we are talking about, I'm wondering if there are OEMs stupid
enough to make a kind of throttling blurb via that interface?

-- 
Bruno Ducrot

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

Re: speedstep capability checks

[aeriksson]

davej@redhat.com said:
>> A few SpeedStep-capable systems don't perform according to
>> specification: the CPUID and/or some MSRs don't tell us the 
>> CPU is SpeedStep capable even though it definitely is.

> Is there nothing in the errata documents about this ? 

<snip>

> I'd merge this really as a last resort, and it's beginning to sound
> like we don't really have any options (other than not support those
> broken boxes). Ugh. 


...and ducrot@poupinou.org replied:
> There is nothing in any data sheets for the check anyway, other than
> it's not possible to distinguish a PIII (coppermine) with Speedstep
> technology from one without Speedstep technology.  There is nothing
> in any spec update I'm aware. 


So, is the patch ok to merge?

/Anders

Re: speedstep capability checks

[Bruno Ducrot]

On Thu, Mar 18, 2004 at 08:57:20PM +0100, aeriksson@fastmail.fm wrote:
> 
> 
> davej@redhat.com said:
> >> A few SpeedStep-capable systems don't perform according to
> >> specification: the CPUID and/or some MSRs don't tell us the 
> >> CPU is SpeedStep capable even though it definitely is.
> 
> > Is there nothing in the errata documents about this ? 
> 
> <snip>
> 
> > I'd merge this really as a last resort, and it's beginning to sound
> > like we don't really have any options (other than not support those
> > broken boxes). Ugh. 
> 
> 
> ...and ducrot@poupinou.org replied:
> > There is nothing in any data sheets for the check anyway, other than
> > it's not possible to distinguish a PIII (coppermine) with Speedstep
> > technology from one without Speedstep technology.  There is nothing
> > in any spec update I'm aware. 
> 
> 
> So, is the patch ok to merge?

To be more precise: if you look only datasheets and spec update,
there is no check given, but there is an application note, and there
is no errata for that AN.
I still don't understand why for example it hasn't been included
in any spec update?

-- 
Bruno Ducrot

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