add new p3m model

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

Quoted 9 lines · 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

arch/i386/kernel/cpu/cpufreq/speedstep-lib.c line 267

Quoted 9 lines

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

arch/i386/kernel/cpu/cpufreq/speedstep-lib.c renamed from arch/i386/kernel/cpu/cpufreq/speedstep-lib.c~ +1 -1

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

Quoted 2 lines

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

Hi,

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

Hi,

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

Quoted 4 lines · 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....

Can you send a /proc/cpuinfo, please?

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

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.

Quoted 6 lines · Dominik Brodowski

Quoted 4 lines · 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....

Quoted 1 line

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

Quoted 2 lines · 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.

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

Quoted 10 lines · Arjan van de Ven

Quoted 7 lines · Dominik Brodowski

Quoted 4 lines · 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....

Can you send a /proc/cpuinfo, please?

Quoted 5 lines

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 [*].

Quoted 16 lines · Dominik Brodowski

Quoted 15 lines · Arjan van de Ven

Quoted 7 lines · Dominik Brodowski

Quoted 4 lines · 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....

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

Quoted 3 lines

                                  ^^^^^^^

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

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

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

Quoted 2 lines · 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.

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

On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:

Quoted 1 line · Dominik Brodowski

I like this patch -- I've modified it a bit so that it applies to

2.6.4 and

Quoted 1 line

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.

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

Quoted 5 lines · On Mon, Mar 15, 2004 at 08:25:28PM +0100, [email protected] 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.

Quoted 14 lines · [email protected] said:

On Mon, Mar 15, 2004 at 03:20:22PM +0100, Arjan van de Ven wrote:

Quoted 1 line · Dominik Brodowski

I like this patch -- I've modified it a bit so that it applies to

2.6.4 and

Quoted 1 line

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.

Quoted 1 line

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

Quoted 3 lines · Dominik Brodowski

(quoted diff) +0 -0

@@ -265,6 +272,12 @@
 		ebx = cpuid_ebx(0x00000001);
 

Review line 282

Quoted 9 lines

(quoted diff) +6 -0

 		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.

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.

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.

Quoted 8 lines · Dominik Brodowski

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

Quoted 3 lines

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 ?

Quoted 15 lines · Dave Jones

Quoted 8 lines · Dominik Brodowski

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

Quoted 5 lines

Quoted 3 lines

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

Quoted 8 lines · Dominik Brodowski

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

Quoted 3 lines

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 ?

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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

Quoted 3 lines

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 ?

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.

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.

Quoted 5 lines · [email protected] said:

Quoted 3 lines

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>

Quoted 3 lines

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 [email protected] replied:

Quoted 4 lines

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?

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

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

Quoted 4 lines

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?

Quoted 4 lines

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?