Hinweis: Das Forum wird geschlossen! Neue Registrierungen sind nicht mehr möglich!

 Zurück zu Pro-Linux   Foren-Übersicht   FAQ     Suchen    Mitgliederliste
Speedstep-SMI + ondemand/conservative auf PIII-mobile+i440BX

 
Neuen Beitrag schreiben   Auf Beitrag antworten    Pro-Linux Foren-Übersicht -> Tips, Tricks, Helferlein
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
komsomolze



Anmeldungsdatum: 03.03.2006
Beiträge: 429

BeitragVerfasst am: 14. Apr 2006 15:10   Titel: Speedstep-SMI + ondemand/conservative auf PIII-mobile+i440BX

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 (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 Wink ):
Code:
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. Wink


----------------------------------------------------------------------------------------------------------
"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:
...
/* #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.
Smile Smile Smile



----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
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.
 
Benutzer-Profile anzeigen Private Nachricht senden

Beiträge vom vorherigen Thema anzeigen:   
     Pro-Linux Foren-Übersicht -> Tips, Tricks, Helferlein Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehen Sie zu:  

Powered by phpBB © phpBB Group
pro_linux Theme © 2004 by Mandaxy