Pro-Linux

Pro-Linux Diskussions- und Hilfeforum
Aktuelle Zeit: 17. Nov 2018 3:34

Alle Zeiten sind UTC+01:00




Ein neues Thema erstellen  Auf das Thema antworten  [ 1 Beitrag ] 
Autor Nachricht
BeitragVerfasst: 14. Apr 2006 15:10 
Offline

Registriert: 03. Mär 2006 23:16
Beiträge: 430
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:
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:
 		if &#40;policy->cpuinfo.transition_latency >
 				&#40;TRANSITION_LATENCY_LIMIT * 1000&#41;&#41; &#123;
 			printk&#40;KERN_WARNING "ondemand governor failed to load "
			       "due to too long transition latency\n"&#41;;
 			return -EINVAL;
 		&#125;
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:
diff  
--- cpufreq_ondemand.c_2617rc1	2006-04-14 07&#58;52&#58;08.315273500 +0200
+++ cpufreq_ondemand.c_2617rc1.my-verbose	2006-04-14 14&#58;04&#58;06.915878750 +0200
@@ -386,25 +386,26 @@
 static int cpufreq_governor_dbs&#40;struct cpufreq_policy *policy,
 				   unsigned int event&#41;
 &#123;
 	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&#40;cpu_dbs_info, cpu&#41;;
 
 	switch &#40;event&#41; &#123;
 	case CPUFREQ_GOV_START&#58;
 		if &#40;&#40;!cpu_online&#40;cpu&#41;&#41; ||
 		    &#40;!policy->cur&#41;&#41;
 			return -EINVAL;
 
 		if &#40;policy->cpuinfo.transition_latency >
 				&#40;TRANSITION_LATENCY_LIMIT * 1000&#41;&#41; &#123;
 			printk&#40;KERN_WARNING "ondemand governor failed to load "
-			       "due to too long transition latency\n"&#41;;
+			       "due to too long transition latency&#58; %x\n", transitlatency &#41;;
 			return -EINVAL;
 		&#125;
 		if &#40;this_dbs_info->enable&#41; /* Already enabled */
 			break;
 
 		mutex_lock&#40;&dbs_mutex&#41;;
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:
include/linux/cpufreq.h&#58;
...
/* #define CPUFREQ_ETERNAL			&#40;-1&#41;*/
#define CPUFREQ_ETERNAL			&#40;10&#41;
...
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.


Nach oben
   
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen  Auf das Thema antworten  [ 1 Beitrag ] 

Alle Zeiten sind UTC+01:00


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste


Sie dürfen keine neuen Themen in diesem Forum erstellen.
Sie dürfen keine Antworten zu Themen in diesem Forum erstellen.
Sie dürfen Ihre Beiträge in diesem Forum nicht ändern.
Sie dürfen Ihre Beiträge in diesem Forum nicht löschen.
Sie dürfen keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Limited
Deutsche Übersetzung durch phpBB.de