* speedstep capability checks
@ 2004-03-14 15:20 aeriksson
2004-03-15 14:15 ` Dominik Brodowski
2004-03-15 18:36 ` Bruno Ducrot
0 siblings, 2 replies; 32+ messages in thread
From: aeriksson @ 2004-03-14 15:20 UTC (permalink / raw)
To: cpufreq
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.");
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: speedstep capability checks 2004-03-14 15:20 speedstep capability checks aeriksson @ 2004-03-15 14:15 ` Dominik Brodowski 2004-03-08 11:15 ` add new p3m model Arjan van de Ven ` (2 more replies) 2004-03-15 18:36 ` Bruno Ducrot 1 sibling, 3 replies; 32+ messages in thread From: Dominik Brodowski @ 2004-03-15 14:15 UTC (permalink / raw) To: aeriksson, davej, Arjan van de Ven; +Cc: cpufreq 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"); ^ permalink raw reply [flat|nested] 32+ messages in thread
* add new p3m model @ 2004-03-08 11:15 ` Arjan van de Ven 2004-03-08 11:47 ` Bas Mevissen 2004-03-08 13:31 ` Bruno Ducrot 0 siblings, 2 replies; 32+ messages in thread From: Arjan van de Ven @ 2004-03-08 11:15 UTC (permalink / raw) To: cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-08 11:15 ` add new p3m model Arjan van de Ven @ 2004-03-08 11:47 ` Bas Mevissen 2004-03-08 11:46 ` Arjan van de Ven 2004-03-08 13:31 ` Bruno Ducrot 1 sibling, 1 reply; 32+ messages in thread From: Bas Mevissen @ 2004-03-08 11:47 UTC (permalink / raw) To: Arjan van de Ven, cpufreq mailing list 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-08 11:47 ` Bas Mevissen @ 2004-03-08 11:46 ` Arjan van de Ven 2004-03-08 12:08 ` Bas Mevissen 0 siblings, 1 reply; 32+ messages in thread From: Arjan van de Ven @ 2004-03-08 11:46 UTC (permalink / raw) To: Bas Mevissen; +Cc: cpufreq mailing list [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-08 11:46 ` Arjan van de Ven @ 2004-03-08 12:08 ` Bas Mevissen 0 siblings, 0 replies; 32+ messages in thread From: Bas Mevissen @ 2004-03-08 12:08 UTC (permalink / raw) To: Arjan van de Ven; +Cc: cpufreq mailing list 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-08 11:15 ` add new p3m model Arjan van de Ven 2004-03-08 11:47 ` Bas Mevissen @ 2004-03-08 13:31 ` Bruno Ducrot 2004-03-14 14:34 ` Dominik Brodowski 1 sibling, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-08 13:31 UTC (permalink / raw) To: Arjan van de Ven; +Cc: cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-08 13:31 ` Bruno Ducrot @ 2004-03-14 14:34 ` Dominik Brodowski 2004-03-15 14:21 ` Arjan van de Ven 0 siblings, 1 reply; 32+ messages in thread From: Dominik Brodowski @ 2004-03-14 14:34 UTC (permalink / raw) To: Bruno Ducrot, Arjan van de Ven; +Cc: cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-14 14:34 ` Dominik Brodowski @ 2004-03-15 14:21 ` Arjan van de Ven 2004-03-15 14:38 ` Dominik Brodowski 0 siblings, 1 reply; 32+ messages in thread From: Arjan van de Ven @ 2004-03-15 14:21 UTC (permalink / raw) To: Bruno Ducrot, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-15 14:21 ` Arjan van de Ven @ 2004-03-15 14:38 ` Dominik Brodowski 2004-03-15 14:45 ` Arjan van de Ven 0 siblings, 1 reply; 32+ messages in thread From: Dominik Brodowski @ 2004-03-15 14:38 UTC (permalink / raw) To: Arjan van de Ven; +Cc: davej, Bruno Ducrot, aeriksson, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-15 14:38 ` Dominik Brodowski @ 2004-03-15 14:45 ` Arjan van de Ven 2004-03-15 15:46 ` Bruno Ducrot 0 siblings, 1 reply; 32+ messages in thread From: Arjan van de Ven @ 2004-03-15 14:45 UTC (permalink / raw) To: Bruno Ducrot, cpufreq, aeriksson, davej [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-15 14:45 ` Arjan van de Ven @ 2004-03-15 15:46 ` Bruno Ducrot 2004-03-15 15:55 ` Dave Jones 0 siblings, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-15 15:46 UTC (permalink / raw) To: Arjan van de Ven; +Cc: davej, aeriksson, cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: add new p3m model 2004-03-15 15:46 ` Bruno Ducrot @ 2004-03-15 15:55 ` Dave Jones 0 siblings, 0 replies; 32+ messages in thread From: Dave Jones @ 2004-03-15 15:55 UTC (permalink / raw) To: Bruno Ducrot; +Cc: Arjan van de Ven, aeriksson, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 14:15 ` Dominik Brodowski 2004-03-08 11:15 ` add new p3m model Arjan van de Ven @ 2004-03-15 14:20 ` Arjan van de Ven 2004-03-15 15:37 ` Bruno Ducrot 2004-03-15 21:09 ` Dave Jones 2 siblings, 1 reply; 32+ messages in thread From: Arjan van de Ven @ 2004-03-15 14:20 UTC (permalink / raw) To: aeriksson, davej, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 14:20 ` speedstep capability checks Arjan van de Ven @ 2004-03-15 15:37 ` Bruno Ducrot 2004-03-15 19:25 ` aeriksson 0 siblings, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-15 15:37 UTC (permalink / raw) To: Arjan van de Ven; +Cc: davej, aeriksson, cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 15:37 ` Bruno Ducrot @ 2004-03-15 19:25 ` aeriksson 2004-03-15 19:35 ` Bruno Ducrot 2004-03-15 19:50 ` [updated patch] " Dominik Brodowski 0 siblings, 2 replies; 32+ messages in thread From: aeriksson @ 2004-03-15 19:25 UTC (permalink / raw) To: Bruno Ducrot; +Cc: davej, Arjan van de Ven, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 19:25 ` aeriksson @ 2004-03-15 19:35 ` Bruno Ducrot 2004-03-15 19:44 ` Arjan van de Ven 2004-03-15 19:50 ` [updated patch] " Dominik Brodowski 1 sibling, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-15 19:35 UTC (permalink / raw) To: aeriksson; +Cc: davej, Arjan van de Ven, cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 19:35 ` Bruno Ducrot @ 2004-03-15 19:44 ` Arjan van de Ven 0 siblings, 0 replies; 32+ messages in thread From: Arjan van de Ven @ 2004-03-15 19:44 UTC (permalink / raw) To: Bruno Ducrot; +Cc: davej, aeriksson, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [updated patch] Re: speedstep capability checks 2004-03-15 19:25 ` aeriksson 2004-03-15 19:35 ` Bruno Ducrot @ 2004-03-15 19:50 ` Dominik Brodowski 1 sibling, 0 replies; 32+ messages in thread From: Dominik Brodowski @ 2004-03-15 19:50 UTC (permalink / raw) To: aeriksson, davej; +Cc: Arjan van de Ven, Bruno Ducrot, cpufreq 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"); ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 14:15 ` Dominik Brodowski 2004-03-08 11:15 ` add new p3m model Arjan van de Ven 2004-03-15 14:20 ` speedstep capability checks Arjan van de Ven @ 2004-03-15 21:09 ` Dave Jones 2004-03-16 7:38 ` Dominik Brodowski 2 siblings, 1 reply; 32+ messages in thread From: Dave Jones @ 2004-03-15 21:09 UTC (permalink / raw) To: aeriksson, Arjan van de Ven, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 21:09 ` Dave Jones @ 2004-03-16 7:38 ` Dominik Brodowski 2004-03-16 13:01 ` Dave Jones 0 siblings, 1 reply; 32+ messages in thread From: Dominik Brodowski @ 2004-03-16 7:38 UTC (permalink / raw) To: Dave Jones; +Cc: Arjan van de Ven, aeriksson, cpufreq 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"); ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 7:38 ` Dominik Brodowski @ 2004-03-16 13:01 ` Dave Jones 2004-03-16 15:01 ` Bruno Ducrot 2004-03-16 16:00 ` Dominik Brodowski 0 siblings, 2 replies; 32+ messages in thread From: Dave Jones @ 2004-03-16 13:01 UTC (permalink / raw) To: aeriksson, Arjan van de Ven, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 13:01 ` Dave Jones @ 2004-03-16 15:01 ` Bruno Ducrot 2004-03-16 15:58 ` Dominik Brodowski 2004-03-16 16:00 ` Dominik Brodowski 1 sibling, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-16 15:01 UTC (permalink / raw) To: Dave Jones; +Cc: Arjan van de Ven, aeriksson, cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 15:01 ` Bruno Ducrot @ 2004-03-16 15:58 ` Dominik Brodowski 0 siblings, 0 replies; 32+ messages in thread From: Dominik Brodowski @ 2004-03-16 15:58 UTC (permalink / raw) To: Bruno Ducrot; +Cc: Dave Jones, Arjan van de Ven, aeriksson, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 13:01 ` Dave Jones 2004-03-16 15:01 ` Bruno Ducrot @ 2004-03-16 16:00 ` Dominik Brodowski 2004-03-16 16:36 ` Bruno Ducrot 1 sibling, 1 reply; 32+ messages in thread From: Dominik Brodowski @ 2004-03-16 16:00 UTC (permalink / raw) To: Dave Jones; +Cc: Arjan van de Ven, aeriksson, cpufreq [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 16:00 ` Dominik Brodowski @ 2004-03-16 16:36 ` Bruno Ducrot 2004-03-18 19:57 ` aeriksson 0 siblings, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-16 16:36 UTC (permalink / raw) To: Dave Jones, aeriksson, Arjan van de Ven, cpufreq > > > 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-16 16:36 ` Bruno Ducrot @ 2004-03-18 19:57 ` aeriksson 2004-03-19 11:06 ` Bruno Ducrot 0 siblings, 1 reply; 32+ messages in thread From: aeriksson @ 2004-03-18 19:57 UTC (permalink / raw) To: Bruno Ducrot, Dave Jones; +Cc: Arjan van de Ven, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-18 19:57 ` aeriksson @ 2004-03-19 11:06 ` Bruno Ducrot 0 siblings, 0 replies; 32+ messages in thread From: Bruno Ducrot @ 2004-03-19 11:06 UTC (permalink / raw) To: aeriksson; +Cc: Dave Jones, Arjan van de Ven, cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-14 15:20 speedstep capability checks aeriksson 2004-03-15 14:15 ` Dominik Brodowski @ 2004-03-15 18:36 ` Bruno Ducrot 2004-03-15 19:20 ` aeriksson 1 sibling, 1 reply; 32+ messages in thread From: Bruno Ducrot @ 2004-03-15 18:36 UTC (permalink / raw) To: aeriksson; +Cc: cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 18:36 ` Bruno Ducrot @ 2004-03-15 19:20 ` aeriksson 2004-03-15 19:36 ` Bruno Ducrot 2004-03-15 19:46 ` Dominik Brodowski 0 siblings, 2 replies; 32+ messages in thread From: aeriksson @ 2004-03-15 19:20 UTC (permalink / raw) To: Bruno Ducrot; +Cc: cpufreq > 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? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 19:20 ` aeriksson @ 2004-03-15 19:36 ` Bruno Ducrot 2004-03-15 19:46 ` Dominik Brodowski 1 sibling, 0 replies; 32+ messages in thread From: Bruno Ducrot @ 2004-03-15 19:36 UTC (permalink / raw) To: aeriksson; +Cc: cpufreq 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: speedstep capability checks 2004-03-15 19:20 ` aeriksson 2004-03-15 19:36 ` Bruno Ducrot @ 2004-03-15 19:46 ` Dominik Brodowski 1 sibling, 0 replies; 32+ messages in thread From: Dominik Brodowski @ 2004-03-15 19:46 UTC (permalink / raw) To: aeriksson; +Cc: Bruno Ducrot, cpufreq 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2004-03-19 11:06 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-03-14 15:20 speedstep capability checks aeriksson 2004-03-15 14:15 ` Dominik Brodowski 2004-03-08 11:15 ` add new p3m model Arjan van de Ven 2004-03-08 11:47 ` Bas Mevissen 2004-03-08 11:46 ` Arjan van de Ven 2004-03-08 12:08 ` Bas Mevissen 2004-03-08 13:31 ` Bruno Ducrot 2004-03-14 14:34 ` Dominik Brodowski 2004-03-15 14:21 ` Arjan van de Ven 2004-03-15 14:38 ` Dominik Brodowski 2004-03-15 14:45 ` Arjan van de Ven 2004-03-15 15:46 ` Bruno Ducrot 2004-03-15 15:55 ` Dave Jones 2004-03-15 14:20 ` speedstep capability checks Arjan van de Ven 2004-03-15 15:37 ` Bruno Ducrot 2004-03-15 19:25 ` aeriksson 2004-03-15 19:35 ` Bruno Ducrot 2004-03-15 19:44 ` Arjan van de Ven 2004-03-15 19:50 ` [updated patch] " Dominik Brodowski 2004-03-15 21:09 ` Dave Jones 2004-03-16 7:38 ` Dominik Brodowski 2004-03-16 13:01 ` Dave Jones 2004-03-16 15:01 ` Bruno Ducrot 2004-03-16 15:58 ` Dominik Brodowski 2004-03-16 16:00 ` Dominik Brodowski 2004-03-16 16:36 ` Bruno Ducrot 2004-03-18 19:57 ` aeriksson 2004-03-19 11:06 ` Bruno Ducrot 2004-03-15 18:36 ` Bruno Ducrot 2004-03-15 19:20 ` aeriksson 2004-03-15 19:36 ` Bruno Ducrot 2004-03-15 19:46 ` Dominik Brodowski
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.