Thinkfan Portierung

lme schrieb:
Ja, aber leider zeigt acpi_ibm bei den neueren Thinkpad-Modellen (wie meinem X230) keine Termperaturen mehr an. :(
Zum Vergrößern anklicken....
Oh, das ist ja blöd. Aber der Lüfter lässt sich steuern? Dann müsste man dem Thinkfan die Möglichkeit spendieren auch Coretemp abfragen zu können. Brauchst du das?
 
Kamikaze schrieb:
Das macht regelungstechnisch gar keinen Sinn.
Zum Vergrößern anklicken....
Ich denke der Autor hat sich folgendes dabei gedacht: normales Abfrageintervall ist 5 Sekunden. Wenn jetzt seit dem letzten Test die Temperatur um mehr als 2 Grad gestiegen ist, dann legt er sich nur noch 2 Sekunden schlafen und prüft dann wieder. Er vermutet einen plötzlichen Lastanstieg, und will den Lüfter halt früher hochdrehen können falls dem so ist.
 
Wenn Du den hohen Anstieg festgestellt hast, ist es ja schon zu spät.

Du musst schlicht den Abtastintervall so wählen dass Du immer schnell genug bist. Schließlich hilft es einem nicht weiter nachträglich festzustellen, das man zu langsam war.
 
Kamikaze schrieb:
Wenn Du den hohen Anstieg festgestellt hast, ist es ja schon zu spät.
Zum Vergrößern anklicken....
Für das letzte Intervall ja. Aber wenn du z.B. ein "make buildworld" startest, dann steigt die Temperatur ja nicht sprunghaft an und verharrt da, aber es ist mit einem schnellen Zuwachs zu rechnen. Bei den folgenden Tests wird dann halt öfter geschaut, bis sich die Temperatur wieder auf einem (anderen) Niveau eingependelt hat. Ich finde das ganz ok so. Man will ja auch nicht sinnlos im Sekundentakt prüfen und unnötig Last erzeugen, was dann selbst zur Erwärmung führen würde.
 
Also, hab das mal probiert (coretemp + acpi_ibm in der loader.conf) - Ergebnis von sysctl dev.acpi_ibm.0.thermal ist, existiert nich. Die Lüfterdrehzal lässt sich per dev.acpi_ibm.0.fan_speed auslesen (das funktioniert auch mit fan_level). CPU Temperaturen bekomme ich über dev.cpu.0.temperature - allerdings ist der Aufruf für jede Core (bei 8) schon etwas umständlich.
 
Kamikaze schrieb:
Das macht regelungstechnisch gar keinen Sinn.
Zum Vergrößern anklicken....
Ich glaub ich bau das doch aus. Ich versuche seit 1 Stunde zu kapieren was der da treibt, aber ich kapiers nicht. Da wird die Temperaturdifferenz zur letzten Messung (Maximaltemperatur aller Sensoren) mit einem "bias_level" multipliziert, auf die Maximaltemperatur addiert und über Pointer in eine der gelesenen Temperaturen drübergeschrieben (keine Ahnung welche, das kriegt man aus dem Spaghetticode nicht raus). Dann wird das bias für die nächste Runde ein bisschen erhöht oder erniedrigt, und im Endeffekt wird eigentlich nur die sleeptime zwischen 2 und 5 Sekunden variiert. Ich glaub den Wahnsinn kann man sich wirklich schenken. Was sich wohl da einer dabei gedacht hat... :confused:
 
Warum schreibst Du das Ding nicht ganz neu ? Machst einen Port draus und betreust selbigen ?
 
Vorher brauchst Du eh ein fertiges und funktionierendes Programm.

Wenn Du nicht vorhaben solltest das langfristig zu betreiben, macht es eh keinen Sinn.
 
Ich denke einfach, dass es keinen Sinn macht, dass nur schnell für Dein ThinkPad zu portieren. Wenn, sollten alle was davon haben und, das erfordert Zeit / Langfristigkeit. Siehe asmc(4) einmal gemacht, durch Google Summer of Code Geld bekommen und, später hinter mir die Sinnflut.
 
Für mich macht es Sinn, weil ich das brauche und mit den vorhandenen Lösungen nicht zufrieden war. Und wenn es jemand anders auch brauchen kann, dann kann er es von meinem Server runter laden wenn ich fertig bin. Klar wäre ein Port noch schöner, müsste ich mich aber auch erst einarbeiten. Aber so fängt doch jedes Projekt an, man fängt doch etwas an weil man es selber braucht (oder Geld dafür bekommt ;))
 
Ja eh, ich hab es nur erwähnt, weil Du ja nicht geschrieben hast, auf was Du im Endeffekt hinaus willst.
 
Kamikaze schrieb:
Klingt nach nutzloser bis gefährlicher Komplexität.
Zum Vergrößern anklicken....
Vor allem macht der Bezug zur Maximaltemperatur überhaupt keinen Sinn. Eine Festplatte hat andere Temperaturen als eine CPU oder GPU. Wenn ich die mische vergleiche ich Äpfel mit Birnen. Und bei meinem T61 kommt noch hinzu, dass die Temperatur für den Zweitakku (den ich nicht habe) mit konstant 50 Grad geliefert wird. Die 50 Grad machen alles kaputt was niedriger ist.
 
Maximaltemperatur ist ein gutes Stichwort. Selbige wird bei mir unter hw.acpi als temp. crit. mit 200 Grad angegeben ;-)
 
NaWi schrieb:
Maximaltemperatur ist ein gutes Stichwort. Selbige wird bei mir unter hw.acpi als temp. crit. mit 200 Grad angegeben ;-)
Zum Vergrößern anklicken....
Nein, so war das nicht gemeint. Mit Maximaltemperatur meinte ich, die höchste gemessene Temperatur aus allen Sensoren. Das ist bei mir häufig die 50 Grad vom nicht-existenten Zweitakku.
 
Schon klar, wie Du das gemeint hast. Anders macht es ja auch keinen Sinn. Aber, wenn der Code so verworren ist, könnten sich ja auch Programmfehler (auch durch neuere Hardwareansteuerungen) auftun. Es könnte ja auch jemand auf die Idee kommen die crit. Werte auszulesen und basierend darauf den fan_level fest zu setzen. Eine weitere Frage ist, ob die 200 Grad stimmen und, wie die restlichen Bestandteile des ThinkPads aussehen, wenn dieser Wert wirklich erreicht werden sollte.
 
NaWi schrieb:
Aber, wenn der Code so verworren ist, könnten sich ja auch Programmfehler (auch durch neuere Hardwareansteuerungen) auftun.
Zum Vergrößern anklicken....
Genau deshalb habe ich das auch rausgeworfen. Was ich nicht verstehe kann ich auch nicht beurteilen ob es 100% korrekt läuft. In dem Thinkfan sind noch mehr so undurchsichtige Sachen drin. Da gibt es z.B. mindestens 3 globale Variablen in denen (vermutlich) immer die Anzahl gefundener Sensoren steht. Die werden an unterschiedlichen Stellen gesetzt und an unterschiedlichen Stellen genutzt, teilweise sogar im selben Kontext gemischt. Beispiel:
Code: 
for (i=0; likely(i < num_temps && temps[i] <= config->limits[lvl_idx].low[i]); i++);
if (unlikely(i >= config->limit_len)) return TRUE;
return FALSE;
Die Schleife läuft bis num_temps, und dann wird mit config->limit_len geprüft ob sie komplett durchgelaufen ist. Da kommt einem das kalte Grausen. :eek:
Das will ich alles noch bereinigen (das meiste hab ich schon), dann bau ich noch coretemp als zweite Sensormöglichkeit ein, und dann lade ich es für Interessierte auf meinen Server hoch.
 
Wenn du nen Port draus bauen möchtest, hilft dir das Porter's Handbook: https://www.freebsd.org/doc/en/books/porters-handbook/

Oder einfach hier im Forum fragen, das bekommen wir schon hin. :)

Zu Coretemp: Wenn's nicht zu umständlich ist, kannst du es gerne einbauen. Ich brauche es zwar nicht, da die Lüftersteuerung ohne Zusatztools schon gut funktioniert, aber möglicherweis können es andere Leute gut gebrauchen.
 
lme schrieb:
Zu Coretemp: Wenn's nicht zu umständlich ist, kannst du es gerne einbauen. ... möglicherweise können es andere Leute gut gebrauchen.
Zum Vergrößern anklicken....
Ja, das dachte ich auch. 2 haben ja schon gemeldet dass bei Ihnen acpi_ibm keine oder falsche Temperaturen liefert. Ich muss nur noch überlegen wie ich das behandle. Bei coretemp hat ja jede Temperatur einen anderen MIB, während acpi_ibm alle 8 Temperaturen in einem MIB liefert. Und dann ist die Anzahl auch noch von der Anzahl CPU-Kerne abhängig. Von der Logik her wären das n Sensoren mit je einer Temperatur. Dann müssten die aber auch n mal ins Config-File rein, und als Parameter der MIB-Name dazu. Das ist blöd für die Pflege des Config files. Aber da fällt mir noch was besseres ein. Ich werde es wohl so machen dass es im Config nur 1 Sensor ist, und der beim parsen dynamisch ver-n-facht wird.
 
JochenF schrieb:
Gibts eigentlich auch andere Lüftersteuerungen, für andere Systeme? Unter Linux gibt's z.B. auch ein Modul für Acer Notebooks.
Zum Vergrößern anklicken....
Unter Linux gibt's auch die "i8k-utils" von Massimo dal Zotto, sehr speziell für die 8000er Modelle des Dell Inspiron. Das habe ich mal auf FreeBSD portiert, weil ich so ein Teil habe. Ist aber kein offizieller Port.
 
So, coretemp ist jetzt auch implementiert. Hab's jetzt doch ganz einfach gemacht: für jede CPU muss eine Zeile mit dem sysctl-Namen in das Config file rein. Die Limits müssen sowieso passend zur Anzahl CPUs bearbeitet werden (alle Temperaturschwellen gleich, aber eben n mal vorhanden). Bei der Arbeit kann man auch gleich die Sensorzeilen duplizieren.

Ich hab noch ein kurzes README dazugeschrieben. Wer's schon mal probieren mag kann es hier runterladen.

Achtung: keine Gewähr für gegrillte CPUs :D
 
Idee: das Problem mit der Lüfterregelung des Herstellers ist ja eigentlich nur, dass der Lüfter zu früh anspringt, obwohl der Rechner grad gar nix zu tun hat. Ansonsten wird die ja hoffentlich passen, und keine CPUs grillen. Wie wäre es, wenn man die manuelle Regelung nur in den unteren Temperaturbereichen macht, und unter Last die Originalregelung regeln lässt? Man könnte ja z.B. ab Level 3 die manuelle Regelung ausschalten, und wenn die Temperatur wieder darunter fällt, wieder übernehmen. Das sollte leicht einzubauen sein. Und dann sollte man eigentlich auf der sicheren Seite sein dass dem Rechner nix passiert.
 
Problem: nach einen Resume vom Suspend ist die manuelle Steuerung wieder ausgeschaltet.

Code: 
$ sudo sysctl dev.acpi_ibm.0.fan=0
dev.acpi_ibm.0.fan: 1 -> 0
nach dem Resume:
Code: 
$ sysctl dev.acpi_ibm.0.fan
dev.acpi_ibm.0.fan: 1
Lässt sich das erkennen dass ein Resume stattgefunden hat? Dann könnte man drauf reagieren und die Initialisierung erneut durchführen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben