Thinkfan Portierung
- Ersteller JochenF
- Erstellt am
Das hört sich aufwendig an. Ich glaub da ist es einfacher ich teste nach jedem sleep() ob dev.acpi_ibm.0.fan noch auf 0 steht.
Ok, dann gehe ich auf Nummer sicher und teste dev.acpi_ibm.0.fan bei jedem Durchlauf. Ich denke das kostet nicht viel. Und wenn es nicht mehr stimmt, dann setze ich es neu.
goblin
Motivierter Amateur
Könnte das damit zusammenhängen, dass die entsprechenden Kernelmodule neu geladen werden und der Zustand im Kernel daher zurückgesetzt wird?
Ansonsten wäre eine Idee, den systctl als Reaktion auf SIGUSR1 zu überprüfen bzw. zu setzen, und bei jedem Resume ein SIGUSR1 an thinkfan zu senden.
Das scheint mir aber genauso ein Hack zu sein, wie in jedem Schleifendurchlauf das sysctl zu überprüfen.
Ansonsten wäre eine Idee, den systctl als Reaktion auf SIGUSR1 zu überprüfen bzw. zu setzen, und bei jedem Resume ein SIGUSR1 an thinkfan zu senden.
Das scheint mir aber genauso ein Hack zu sein, wie in jedem Schleifendurchlauf das sysctl zu überprüfen.
Ich möchte die korrekte Funktionsweise ungern in die Hände eines externen "Hilfsprogramms" legen. Das soll schon von ganz alleine zuverlässig arbeiten.
Gibts Beispiele wie sowas zu machen wäre?
Ich kann mir aber nicht vorstellen dass das effizienter sein soll. Das lesen des fan Status dürfte doch nur ein simpler Speicherzugriff sein, ich kann mir nicht vorstellen dass das Resourcen frisst. Das festellen ob die Pipe neue Daten hat dürfte teurer sein. Und @Kamikaze schrieb ja auch, dass es u.U. auch andere Konstellationen gibt die einen Reset bewirken. Nur auf die Pipe lauschen erscheint mir da nicht sicher genug.
lme
FreeBSD Committer
Schau mal hier: http://bsd-geek.de/git/?p=acpi_keyd.git;a=tree
Da wird an der pipe gelauscht und die aufkommenden Events geparst.
Der große Vorteil dabei ist, dass es ohne Polling funktioniert.
Da wird an der pipe gelauscht und die aufkommenden Events geparst.
Der große Vorteil dabei ist, dass es ohne Polling funktioniert.
Wenn ich das Beispiel richtig verstehe ist das aber ein blockierendes Lesen, das hilft mir nix. Das müsste man dann in einem parallelen Thread machen, das wird mir zu kompliziert. Ich mach's erstmal auf die simple Weise, vielleicht mag das ja später jemand anders einbauen.
In deinem Fall macht das keinen Sinn, weil Du sowieso pollst.
Du könntest Deine Lüftersteuerung aber auch Event-basiert bauen. Das wäre dann ohne polling, das heißt dein Programm würde komplett schlafen, wenn die Temperatur sich nicht ändert.
Temperatur-Events:
!system=ACPI subsystem=Thermal type=\_TZ_.TZ0_ notify=0x81
!system=ACPI subsystem=Thermal type=\_TZ_.TZ0_ notify=0x80
Resume:
!system=ACPI subsystem=Resume type=\ notify=0x03
Leider gibt es für die coretemp Werte keine Events. Bei mir ist tz0 der einzige erkannte Sensor und der klemmt immer auf 14°C, während die coretemp Temperaturen zwischen realistischen 48 °C und 84 °C schwanken.
Du könntest Deine Lüftersteuerung aber auch Event-basiert bauen. Das wäre dann ohne polling, das heißt dein Programm würde komplett schlafen, wenn die Temperatur sich nicht ändert.
Temperatur-Events:
!system=ACPI subsystem=Thermal type=\_TZ_.TZ0_ notify=0x81
!system=ACPI subsystem=Thermal type=\_TZ_.TZ0_ notify=0x80
Resume:
!system=ACPI subsystem=Resume type=\ notify=0x03
Leider gibt es für die coretemp Werte keine Events. Bei mir ist tz0 der einzige erkannte Sensor und der klemmt immer auf 14°C, während die coretemp Temperaturen zwischen realistischen 48 °C und 84 °C schwanken.
ich hab dein thinkfan mal auf mein t420 ausprobiert.
Der scheint immer zwischen an und aus zuwechseln, dabei faellt die temperatur nicht unter den schwellwert
config
hab ich da was in der config falsch?
Der scheint immer zwischen an und aus zuwechseln, dabei faellt die temperatur nicht unter den schwellwert
config
Code:
cpu_temp dev.cpu.0.temperature
cpu_temp dev.cpu.2.temperature
#
# Next we specify the fan we want to use. On a Thinkpad, this is:
#
tp_fan dev.acpi_ibm.0.fan
{ "0" # the fan level
(0 0 )
(40 40 )
}
{ "1"
(48 48 )
(58 58 )
}
{ "3"
(52 52 )
(62 62 )
}
{ "5"
(56 52 )
(63 63 )
}
{ "7"
(61 55 )
(. . )
}
Code:
trigger=-1, temp=-1 -> fan="0"
trigger=0, temp=48 -> fan="1"
trigger=-1, temp=-1 -> fan="0"
trigger=0, temp=47 -> fan="1"
trigger=-1, temp=-1 -> fan="0"
trigger=0, temp=49 -> fan="1"
trigger=-1, temp=-1 -> fan="0"
trigger=0, temp=47 -> fan="1"
trigger=-1, temp=-1 -> fan="0"
trigger=0, temp=46 -> fan="1"
trigger=-1, temp=-1 -> fan="0"hab ich da was in der config falsch?
Was "falsch" oder "richtig" ist, ist allein deine Entscheidung. Das Muster-Konfig-File ist lediglich ein Muster. Beobachte erstmal mit dem beiliegenden Programm cputemp (make cputemp) wie die Temperaturen auf deinem System sind. Im Idle-Mode und unter Vollast. Und dann entscheide wie du die Lüfterstufen einteilen möchtest. Am besten liest du dir auch mal das Thinkwiki dazu durch, und das README.
Desweiteren fällt mir auf dass du die Temperatur von CPU 0 und 2 misst. Was ist mit 1 und 3? Du solltest alle Kerne berücksichtigen!
haegga, lade dir das thinkfan nochmal runter. Ich hab das cputemp so erweitert dass es selber die Anzahl CPUs ermittelt, dann brauchst du das nicht im Sourcecode ändern. Es zeigt dir automatisch für jeden Kern die Temperatur an.
Und vielleicht hilft dir diese Kurzerklärung:
Jede Lüfterstufe hat einen unteren und einen oberen Temperaturwert. Wird der obere überschritten, wird auf die nächst höhere Stufe geschaltet. Wird der untere unterschritten, wird auf die nächst niedrigere Stufe geschaltet. Und das natürlich über alle Sensoren ermittelt. Für raufschalten reicht ein Sensor der überschritten wurde, für runterschalten muss die Bedingung bei allen erfüllt sein. Wenn du coretemp verwendest sollten natürlich alle Sensoren die gleichen Werte haben. Unterschiede machen nur Sinn wenn die Sensoren unterschiedliche Temperaturen messen, also z.B. CPU und Festplatte.
Und vielleicht hilft dir diese Kurzerklärung:
Jede Lüfterstufe hat einen unteren und einen oberen Temperaturwert. Wird der obere überschritten, wird auf die nächst höhere Stufe geschaltet. Wird der untere unterschritten, wird auf die nächst niedrigere Stufe geschaltet. Und das natürlich über alle Sensoren ermittelt. Für raufschalten reicht ein Sensor der überschritten wurde, für runterschalten muss die Bedingung bei allen erfüllt sein. Wenn du coretemp verwendest sollten natürlich alle Sensoren die gleichen Werte haben. Unterschiede machen nur Sinn wenn die Sensoren unterschiedliche Temperaturen messen, also z.B. CPU und Festplatte.
Die CPU hat 2 cores + HT. Deswegen nehme ich nur 0 und 2.
Ich sehe auch gerade meinen fehler, ich dachte er sollte auf fan level 0 zurueck schalten wenn er unter 40C ist, da hab ich mich in der Zeile vertan. Das tut er natuerlich schon ab 48.
Ich find dein default Werte etwas hoch, 54C sind fuer eine CPU nicht kritisch, aber damit erwaerrmt man alle andere komponenten im Laptop.
Was noch top waere ist support fuer den nvidia Treiber
Da sollte man auch irgend wie Werte auslesen koennen. Aber danke fuer den Port, den hatte ich mir schon laenger gewuenscht.
Wobei bei man bei einen T420 eigentlich kein extra tool braucht.
Ich sehe auch gerade meinen fehler, ich dachte er sollte auf fan level 0 zurueck schalten wenn er unter 40C ist, da hab ich mich in der Zeile vertan. Das tut er natuerlich schon ab 48.
Ich find dein default Werte etwas hoch, 54C sind fuer eine CPU nicht kritisch, aber damit erwaerrmt man alle andere komponenten im Laptop.
Was noch top waere ist support fuer den nvidia Treiber
Da sollte man auch irgend wie Werte auslesen koennen. Aber danke fuer den Port, den hatte ich mir schon laenger gewuenscht.Wobei bei man bei einen T420 eigentlich kein extra tool braucht.
Mein Beispiel für coretemp war nur schnell reingehackt, einfach nur als Beispiel. Ich verwende den acpi_ibm Sensor. Liefert der bei dir nix sinnvolles?
Wenn jemand einen Link hat (oder manpage) mit welchem Modul man wie die nvidia Temperaturen liest, dann kann ich das gerne einbauen.
Wenn jemand einen Link hat (oder manpage) mit welchem Modul man wie die nvidia Temperaturen liest, dann kann ich das gerne einbauen.
Nur für den Fall dass jemand nicht von alleine drauf kommt: man kann die Temperatursensoren von coretemp und acpi_ibm auch kombinieren. 
Weiss nur noch nicht ob das gut ist. Bei mir liefert der IBM-Sensor eine um durchschnittlich 11 Grad niedrigere Temperatur als der CPU-Kern. Offensichtlich ist der Sensor wohl äußerlich am Gehäuse angebracht. Die Kerntemperatur ist sicherlich genauer und reagiert schneller, die Frage ist aber ob man das wirklich will. Will man auf jede kurzzeitige Schwankung reagieren, oder wird die Regelung dann nicht eher "zu hektisch"?
Weiss nur noch nicht ob das gut ist. Bei mir liefert der IBM-Sensor eine um durchschnittlich 11 Grad niedrigere Temperatur als der CPU-Kern. Offensichtlich ist der Sensor wohl äußerlich am Gehäuse angebracht. Die Kerntemperatur ist sicherlich genauer und reagiert schneller, die Frage ist aber ob man das wirklich will. Will man auf jede kurzzeitige Schwankung reagieren, oder wird die Regelung dann nicht eher "zu hektisch"?