Hallo,
nach Hinweisen aus dem Internet konnte ich endlich speedstep-smi starten:
- (/etc/modprobe.d/LOCAL)
options speedstep-lib relaxed_check=1
options speedstep-smi smi_port=0xb2 smi_cmd=0x82 smi_sig=1
- powernowd+cpuspeed(userspace) cpudynd(performance<->powersave)
Code: Select all
echo -n ondemand/conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
----------------------------------------------------------------------------------------------------------
Um Meldungen/Messages zu bekommen:
Beim Lesen von Changelog-2.6.17rc1 wurde eine ondemand.c hinzugefügte Meldung erwähnt:
Code: Select all
if (policy->cpuinfo.transition_latency >
(TRANSITION_LATENCY_LIMIT * 1000)) {
printk(KERN_WARNING "ondemand governor failed to load "
"due to too long transition latency\n");
return -EINVAL;
}
in conservative.c und ondemand.c wurden einige Sachen korrigiert (conservative und ondemand sind "ungleiche" Geschwister), und da es mir um die beiden geht habe ich (nur) diese Teile des Patches auch angewendet.
Den Meldungseintrag habe ich etwas modifiziert (tschuldigung, ich kann kein C ):
Code: Select all
diff
--- cpufreq_ondemand.c_2617rc1 2006-04-14 07:52:08.315273500 +0200
+++ cpufreq_ondemand.c_2617rc1.my-verbose 2006-04-14 14:04:06.915878750 +0200
@@ -386,25 +386,26 @@
static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
unsigned int event)
{
unsigned int cpu = policy->cpu;
struct cpu_dbs_info_s *this_dbs_info;
unsigned int j;
+ unsigned int transitlatency = policy->cpuinfo.transition_latency;
this_dbs_info = &per_cpu(cpu_dbs_info, cpu);
switch (event) {
case CPUFREQ_GOV_START:
if ((!cpu_online(cpu)) ||
(!policy->cur))
return -EINVAL;
if (policy->cpuinfo.transition_latency >
(TRANSITION_LATENCY_LIMIT * 1000)) {
printk(KERN_WARNING "ondemand governor failed to load "
- "due to too long transition latency\n");
+ "due to too long transition latency: %x\n", transitlatency );
return -EINVAL;
}
if (this_dbs_info->enable) /* Already enabled */
break;
mutex_lock(&dbs_mutex);
(policy->cpuinfo.transition_latency)=(ffffffff), was hier zum Abbruch führt.
Wegen der Gleichheit von ondemand mit conservative würde dort wohl dasselbe herauskommen.
Nach dieser Ausgabe habe ich meine Modifikation schnell wieder entfernt, weil, ich kann halt kein C.
----------------------------------------------------------------------------------------------------------
"Analyse/Analysis":
Eine Suche nach "cpuinfo.transition_latency" in den Kernel-Quellen brachte in allen cpufreq-Speedstepping-Modulen:
- ...
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
...
- ...
#define CPUFREQ_ETERNAL (-1)
...
----------------------------------------------------------------------------------------------------------
Meine Lösung/Solution:
Ich habe jetzt auf GutGlück geändert (in ondemand.c steht "...transition latency <= 10mS ..."):
Code: Select all
include/linux/cpufreq.h:
...
/* #define CPUFREQ_ETERNAL (-1)*/
#define CPUFREQ_ETERNAL (10)
...
Und jetzt werden diese Governor angenommen und arbeiten. (automatisches Speedstepping 1000MHz <-> 700MHz)
Die Userspace-Daemonen wie powernowd, cpuspeed oder cpudynd brauche ich nicht mehr.
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Ich habe dieses Hacking durchgeführt weil ich nicht glaubte, dass die Governor grundsätzlich bei mir nicht arbeiten.
Ich traute der BIOS-Implementierung halt nicht:
Beim Laden von speedstep_smi tauchten die oben angegebenen Modul-Parameter (port, cmd, sig) auf, waren aber "vertauscht"
> dsdt-Dekompilate habe ich nicht verstanden > dann in den Kernel-Quellen gesucht, zuerst in acpi, dann in cpufreq/speedstep.