* bad ACPI tables for Dothan?
[not found] ` <4106EB87.4010603@gmx.de>
@ 2004-07-28 0:13 ` Jeremy Fitzhardinge
2004-07-28 0:32 ` Frederik Reiss
2004-07-28 13:25 ` Frederik Reiss
0 siblings, 2 replies; 5+ messages in thread
From: Jeremy Fitzhardinge @ 2004-07-28 0:13 UTC (permalink / raw)
To: Frederik Reiss; +Cc: cpufreq list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bad ACPI tables for Dothan?
2004-07-28 0:13 ` bad ACPI tables for Dothan? Jeremy Fitzhardinge
@ 2004-07-28 0:32 ` Frederik Reiss
2004-07-28 13:25 ` Frederik Reiss
1 sibling, 0 replies; 5+ messages in thread
From: Frederik Reiss @ 2004-07-28 0:32 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: cpufreq
-----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-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: bad ACPI tables for Dothan?
@ 2004-07-28 0:59 paul.devriendt
0 siblings, 0 replies; 5+ messages in thread
From: paul.devriendt @ 2004-07-28 0:59 UTC (permalink / raw)
To: jeremy, frederikreiss; +Cc: cpufreq
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bad ACPI tables for Dothan?
2004-07-28 0:13 ` bad ACPI tables for Dothan? Jeremy Fitzhardinge
2004-07-28 0:32 ` Frederik Reiss
@ 2004-07-28 13:25 ` Frederik Reiss
2004-07-28 17:30 ` Dominik Brodowski
1 sibling, 1 reply; 5+ messages in thread
From: Frederik Reiss @ 2004-07-28 13:25 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: cpufreq
-----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-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bad ACPI tables for Dothan?
2004-07-28 13:25 ` Frederik Reiss
@ 2004-07-28 17:30 ` Dominik Brodowski
0 siblings, 0 replies; 5+ messages in thread
From: Dominik Brodowski @ 2004-07-28 17:30 UTC (permalink / raw)
To: Frederik Reiss; +Cc: Jeremy Fitzhardinge, cpufreq
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;
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-07-28 17:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <410557B4.6060303@gmx.de>
[not found] ` <1090872497.8114.3.camel@localhost>
[not found] ` <41061454.90306@gmx.de>
[not found] ` <1090965071.16558.2.camel@localhost>
[not found] ` <4106E08D.3000909@gmx.de>
[not found] ` <1090970168.16558.7.camel@localhost>
[not found] ` <4106EB87.4010603@gmx.de>
2004-07-28 0:13 ` bad ACPI tables for Dothan? Jeremy Fitzhardinge
2004-07-28 0:32 ` Frederik Reiss
2004-07-28 13:25 ` Frederik Reiss
2004-07-28 17:30 ` Dominik Brodowski
2004-07-28 0:59 paul.devriendt
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.