banias with different (unusual?) model_name

hi jeremy

i've found a pentium-m banias which reports "Mobile Genuine Intel(R)
processor 1400MHz" in /proc/cpuinfo. this (strange?) signature
prevents speedstep-centrino.c from working properly.

the machine is a asus L4000R-series (L4510RBP) pentium-m/ati9100igp notebook.

"Enhanced SpeedStep" works as advertised for this particular pentium-m with the following trivial patch applied:

# diff -up arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.default arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.default	2004-08-19 19:53:59.000000000 +0200
+++ arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-08-19 20:49:06.000000000 +0200
@@ -195,7 +195,7 @@ static struct cpufreq_frequency_table ba

#define _BANIAS(cpuid, max, name) \
{ .cpu_id = cpuid, \
- .model_name = "Intel(R) Pentium(R) M processor " name "MHz", \
+ .model_name = "Mobile Genuine Intel(R) processor " name "MHz", \
.max_freq = (max)*1000, \
.op_points = banias_##max, \
}

it seems that only the model_name is different for this CPU?

thias

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 9
model name	: Mobile Genuine Intel(R) processor       1400MHz
stepping	: 5
cpu MHz		: 600.087
cache size	: 1024 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 mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est
bogomips	: 1190.18

Matthias Brill <[email protected]>

Signatures appear to be BIOS set so that would make sense.

hi alan, jeremy

that fact wasn't obvious to me -- i've updated the BIOS and the strange banias signature is now gone. it reports the expected "Intel(R) Pentium(R) M processor 1400MHz" string now.

in excess the "ACPI-behaviour" changes from "totally broken" to "not working" which is kind of a progress... 8-}

it seems that the reported value depends on the mental health of the BIOS-programmer at hand, therefore the suplied string might not be trustworthy.

if i understand correctly, the type of the cpu can be determined by looking at the family, model and stepping -- assuming that these values are reported directly by the CPUID (0FA2) instruction.

the BIOS supplied model_name string in speedstep-centrino.c is parsed to get the clock cycle time of the cpu. is this actually supposed to be the "right" way (or worse: the only way) to get this information?

thias

Matthias Brill <[email protected]>

_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq

download the source for x86info sometime, and look at the hoops it jumps through to determine what cpu its running on. It isn't just as simple as a few cpuid calls any more. These days there are typically up to a half dozen factors that you need to look at to discriminate between possibilities. One of these, is cpu speed. Unfortunatly, as we could have booted off mains, and hence a lower clock speed, we can't do any runtime calculation like we do with bogomips/jiffies, so we have to resort to looking at the model name supplied by the BIOS.

It's pretty much all we have that we can trust. If we could do something else, I'd love to, as I distrust the abilities of BIOS programmers as much as anyone else.

Dave

Thanks. The driver looks a bit different now, so I've recast the patch.

David, could you put this in your tree?

Thanks,
J

 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c |    3 +++
 1 files changed, 3 insertions(+)

diff -puN arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c~sc-ac-dothan-a2 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
@@ -53,12 +53,14 @@ struct cpu_id
 enum {
 	CPU_BANIAS,
 	CPU_DOTHAN_A1,
+	CPU_DOTHAN_A2,
 	CPU_DOTHAN_B0,
 };
 
 static const struct cpu_id cpu_ids[] = {
 	[CPU_BANIAS]	= { 6,  9, 5 },
 	[CPU_DOTHAN_A1]	= { 6, 13, 1 },
+	[CPU_DOTHAN_A2]	= { 6, 13, 2 },
 	[CPU_DOTHAN_B0]	= { 6, 13, 6 },
 };
 #define N_IDS	(sizeof(cpu_ids)/sizeof(cpu_ids[0]))

@@ -221,6 +223,7 @@ static struct cpu_model models[] =
 
 	/* NULL model_name is a wildcard */
 	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },
+	{ &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },
 	{ &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },
 
 	{ NULL, }

_

_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq

ACK. Merged, and queued for next weeks mainline cpufreq patchbomb.

Dave

Thanks. Is that aimed at 2.6.9, or 2.6.8.2? Sooner the better for me, since a lot of people seem to be mailing me about Dothan...

J

I'll ask Linus to pull as soon as he gets back. My guess is that 2.6.8.2 would be reserved for anything really critical, so its likely they'll turn up in 2.6.9rc1.

Dave

Yeah, there seem to be a few of these around. I'm just not certain that they're identical to "normal" Banias as far as operating points go.

J