Speedstep-SMI + ondemand/conservative auf PIII-mobile+i440BX

[komsomolze]

Speedstep-SMI + ondemand/conservative auf Pentium PIII-mobile ( Coppermine 1GHz, i440BX (piix4)( Medion 9580A, Asus L8400C )) mit 2.6.16-vanilla


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

Dann funktionierten die Userspace-Programme:

• powernowd+cpuspeed(userspace) cpudynd(performance<->powersave)

Wenn ich aber die Kernel-Alternative nutzen wollte, wurde kommentarlos nichts eingetragen bei

Code: Select all

echo -n ondemand/conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

(trotz KernelParameter cpufreq.debug=7)



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

Zum grössten Teil ist dieser Patch fuer die cpufreq-Module und -Governors reine Schönheitskorrektur zu 2.6.16,
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);

sodass beim 'echo ondemand > scaling-governor' sinngemäss gemeldet wurde:
(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;
  ...

Eine weitere Suche nach "CPUFREQ_ETERNAL" brachte in include/linux/cpufreq.h:

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

Noch ein 'make modules; make modules_install' und Neuladen der Module cpufreq_ondemand und cpufreq_conservative.
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.