bad ACPI tables for Dothan?

bad ACPI tables for Dothan?

[Jeremy Fitzhardinge]

On Wed, 2004-07-28 at 01:55 +0200, Frederik Reiss wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeremy Fitzhardinge schrieb:
> | Ah, OK, a bit more information.  Looks like there's a strange table in
> | your ACPI.  See what this shows.
> |
> | 	J
> Hi again, here are the requested informations:
> 
> Jul 28 01:45:17 localhost kernel: invalid encoded frequency: ffff (0kHz)
> != 25500000
> Jul 28 01:45:17 localhost kernel: speedstep-centrino: no table support
> for CPU model "Intel(R) Pentium(R) M processor 1.50GHz":
> Jul 28 01:45:17 localhost kernel: speedstep-centrino: try compiling with
> CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled

OK, I'm out of my depth.  I really don't know anything about ACPI or
these tables, but they look corrupted.  It seems that you have an entry
for a 25GHz CPU...

I'm CC:ing the cpufreq list, since someone there might have better
suggestions.


cpufreq folks: Frederik has a Tosiba M30-851 laptop with this CPU:

vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.50GHz
stepping        : 6
cpu MHz         : 1496.370
flags           : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca
cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe tm2 est
bogomips        : 2957.31

In theory the ACPI tables should work fine for this Dothan, but they
seem corrupt.  It seems that centrino_cpu_init_acpi() is getting a
0xffff control register value, and a corresponding 25GHz CPU core speed.
I'm assuming there's someone who knows what this means.

	J

Re: bad ACPI tables for Dothan?

[Frederik Reiss]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Fitzhardinge schrieb:

| cpufreq folks: Frederik has a Tosiba M30-851 laptop with this CPU:

It's a Toshiba M30-951 ... sorry my fault


- --
Es gibt einen neuen Aufkleber für die A-Klasse?
"Ich bremse nicht für Elche!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBBvQJcLHece3p3gARAowdAJ0UggOhFbzjYwvCafxkQtfvSvaloACgimNe
e9WuHvwuvTHl6Q5FgfwI/bY=
=McZk
-----END PGP SIGNATURE-----

Re: bad ACPI tables for Dothan?

[Frederik Reiss]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Fitzhardinge schrieb:

| In theory the ACPI tables should work fine for this Dothan, but they
| seem corrupt.  It seems that centrino_cpu_init_acpi() is getting a
| 0xffff control register value, and a corresponding 25GHz CPU core speed.
| I'm assuming there's someone who knows what this means.
|
| 	J


Hi,

I found the Problem:

The ACPI table has 16 entrys, but only the first 5 entrys are valid
values the rest of them seems to have 0xffff as value.

If i add the line "p.state_count=5;" before line 345 in the
speedstep-centrino.c which you send me it works perfect for me.

Hope this helps :)

- --
He was always at a loss when people acted like this. When machines went
funny you just oiled them or prodded them or, if nothing else worked, hit
them with a hammer. Nomes didn't respond well to this treatment.
(Diggers)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBB6lVcLHece3p3gARAqP0AJ99o/K+71vW8RyLIuzWjeBznxcWUwCgwKN4
pHfeF4VhO7npc8OJlBSbHKw=
=rlBJ
-----END PGP SIGNATURE-----

Re: bad ACPI tables for Dothan?

[Dominik Brodowski]

Could you try this patch, please?

Thanks,
	Dominik

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-07-28 19:02:28.271709968 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-07-28 19:29:18.406932208 +0200
@@ -347,6 +347,12 @@
 			goto err_unreg;
 		}
 
+		if (!p.states[i].core_frequency > p.states[0].core_frequency) {
+			printk(KERN_DEBUG "P%u has larger frequency than P0, skipping\n");
+			p.states[i].core_frequency = 0;
+			continue;
+		}
+
 		if (extract_clock(p.states[i].control) != 
 		    (p.states[i].core_frequency * 1000)) {
 			printk(KERN_DEBUG "Invalid encoded frequency\n");
@@ -378,6 +384,8 @@
 		centrino_model->op_points[i].frequency = p.states[i].core_frequency * 1000;
 		if (cur_freq == centrino_model->op_points[i].frequency)
 			p.state = i;
+		if (!p.states[i].core_frequency)
+			centrino_model->op_points[i].frequency = CPUFREQ_ENTRY_INVALID;
 	}
 	centrino_model->op_points[p.state_count].frequency = CPUFREQ_TABLE_END;

RE: bad ACPI tables for Dothan?

[paul.devriendt]

> In theory the ACPI tables should work fine for this Dothan, but they
> seem corrupt.  It seems that centrino_cpu_init_acpi() is getting a
> 0xffff control register value, and a corresponding 25GHz CPU 
> core speed.
> I'm assuming there's someone who knows what this means.

I do not *know* the answer, but can offer a comment based on 
looking at some ACPI tables for AMD processors. I have seen
some ACPI BIOSs where -1 in an entry seems to mean not valid.
I.e., instead of telling you there are 4 entries and giving
you 4 valid sets of data, you get 5 entries of which 1 is filled
with -1. I added code to the AMD Athlon64 driver to just ignore
anything that was filled with -1.

Paul.