Am 27. Oktober 2014 17:57 schrieb Joachim H. :

gkrellm und xosview zeigen die selben Werte. Das spricht gegen einen Bug sondern für ein generelles Problem wie es im von Martin angebrachten Bugreport steht.

Da zeigt xosview aber gar keine Temperaturen an. Auf anderen CPUs läuft das bei mir korrekt. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo, Am Mon, 27 Oct 2014, Joachim H. schrieb:

Am 25.10.2014 um 16:49 schrieb David Haller:

...

Die, die der Sensor ausliest.

Guck dir mal die Manpages von sensors, sensors.conf und sensors-detect an.

uih, Pfannkuchen mit Tomatensoße. Das ist mir etwas zu komplex. Ohne dezidierte Hardwarekenntnisse ist da nix zu machen.

Doch, schon ;) Du mußt halt nur mal 'sensors-detect' aufrufen, und dann ggfs. die /etc/sysconfig/lm_sensors anpassen. K.A. ob das auch via Yast2 irgendwie geht. Aber du solltest vorher wissen, was du da machst, daher erstmal nur der Hinweis auf die manpages ... Bei mir z.B.: # sensors-detect [gekürzt] Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): [..] AMD Family 10h thermal sensors... Success! (driver `k10temp') [..] Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): [..] Found `ITE IT8720F Super IO Sensors' Success! (address 0x228, driver `it87') [..] Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `it87': * ISA bus, address 0x228 Chip `ITE IT8720F Super IO Sensors' (confidence: 9) Driver `k10temp' (autoloaded): * Chip `AMD Family 10h thermal sensors' (confidence: 9) Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): no Du könntest da mal 'yes' sagen, evtl. braucht's noch ne neue initrd, als mkinitrd / dracut aufrufen ... Ich verwende hier allerdings: HWMON_MODULES="it87 i2c-piix i2c-dev k8temp" MODULE_0=k8temp MODULE_1=i2c-piix4 MODULE_2=i2c-dev MODULE_3=it87 Warum ich da k10temp sondern explizit k8temp nicht angebe weiß ich nimmer ... Im gkrellm wird aber k10temp verwendet (mit etwas niedrigen Werten, nur 36°C statt den realistischeren ~46°C des it87). Da auch der it87 Wert auch unter Dauervolllast auf beiden Kernen nicht mehr über IIRC ~53°C rauskommt (überdimensionierter Kühler/Lüfter mit grad mal max. 1300^-1min regelt! :) Die (zu niedrige) k10temp hab ich mir in letzter Zeit gar nicht mehr anzeigen lassen, erst wg. diesem Thread hab ich die mal wieder eingeblendet ;) Im Grunde ist's jedenfalls einfach das 'sensors-detect' aufrufen ;)

Da ich die tatsächlichen Core-Temperaturen auch nicht kenne, wüsste ich nicht auf welche Werte ich justieren sollte.

Ideal wäre natürlich, wenn du ein Infrarot-Thermometer hättest ;) Ansonsten könntest du mal im BIOS/UEFI gucken, ob da auch schon Temperaturen angezeigt werden. Das gäbe schonmal ne erste Hausnummer. Ansonsten: Du kannst davon ausgehen, daß die CPU bei guter Kühlung immer noch einiges über der Zimmertemperatur liegt. Du mußt dann halt gucken, was die Sensoren ausspucken, ein bissl konservativ schätzen und aufrunden ... Ich bin jetzt aber zu faul nachzugucken, wie ich beim sensors den Offset einbau, beim gkrellm ist's hier wie gesagt ausgegraut (auch als root). Naja, was für ne CPU hast du nochmal? Jedenfalls kann man da ja die spezifizierten Temperaturen nachgucken, bei aktuellen Intel-CPUs gibt's ja eh ein TDP-Budget das durch die Turbo-Stufen ausgeschöpft werden soll ... IIRC geht das bis >> 70°C (eher deutlich mehr, 85°?) Not-Drosselung schlägt IIRC erst bei 90°C zu oder so ... AMD liegt deutlich niedriger (70/75? k.A.) ... Das nur mal so als Hausnummern, was Obergrenzen angeht ...

...

Prinzipiell mußt du eben ein Offset angeben. Bei gkrellm geht das z.B. in der GUI, bei xosview mußt du wohl in der sensors config schrauben.

gkrellm und xosview zeigen die selben Werte. Das spricht gegen einen Bug sondern für ein generelles Problem wie es im von Martin angebrachten Bugreport steht.

Ist i.d.R. ein "Bug" der HW bzw. des sensors-Treiber, wobei letzterer eben schlicht und einfach nicht für jede MoBo/CPU Kombination Korrekturwerte enthalten kann, IMO. Wenn du nicht pragmatisch wie ich die Werte einfach als relativ ansiehst, dann mußt du halt doch manpages wälzen oder ganz lieb fragen ;) -dnh -- Das Ulkige an Linux: Man will sich nur eben ein Mailprogramm einrichten, aber danach kann man dann wahrscheinlich im Heizungskeller gleich sein eigenes GMX aufmachen. -- Stephan Maus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo, Am Mon, 27 Oct 2014, Roman Fietze schrieb:

On Mon, 27.10.2014 11:22:26 Christian Meseberg wrote:

...

Wo müsste ich drehen, um die Temperaturanzige zu sehen?

/usr/share/X11/app-defaults/XOsview:

*coretemp: False

auf True setzen.

*patsch* Du sollst in /usr/ nix editieren! Das gehört in ~/.Xresources rein: xosview*coretemp: True Ich hab da z.B. schon: xosview*net: True xosview*disk: True xosview*int: False Achso, und systemweit gehört's nach /etc/X11/Xresources. HTH, -dnh --

A clock that gains a minute a day will only be right once every couple of years (approximately). -- Paul Martin It should stand for election. It's doing better than your average politico. -- Peter Corlett -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo, Am Mon, 27 Oct 2014, Peter Geerds schrieb:

Am 27.10.2014 um 12:54 Uhr schrieb David Haller:

...

...

On Mon, 27.10.2014 11:22:26 Christian Meseberg wrote: /usr/share/X11/app-defaults/XOsview:

*coretemp: False

auf True setzen. [..] Das gehört in ~/.Xresources rein:

Hat das einen tieferen Grund, warum du dafür keine ~/.Xdefaults verwendest?

$ find /etc/X11/ -iname 'xdefault*' $ ls -l ~/.Xdefaults ~/.Xresources lrwxrwxrwx 1 dh dh 11 Mar 25 2012 /home/dh/.Xdefaults -> .Xresources -rw-r--r-- 1 dh dh 10885 May 3 2013 /home/dh/.Xresources ==== /etc/X11/xinit/xinitrc.common ==== [..] XETCDIR=/etc/X11 xdefaults=$HOME/.Xdefaults xresources=$HOME/.Xresources [..] # # Handle the system and the users Xresources # if test -r "$xdefaults" ; then if test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources xrdb -I$HOME -merge "$xdefaults" else xrdb -I$HOME -load -retain "$xdefaults" fi if test -r "$xresources" ; then xrdb -I$HOME -merge "$xresources" fi elif test -r "$xresources" ; then if test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources xrdb -I$HOME -merge "$xresources" else xrdb -I$HOME -load -retain "$xresources" fi elif test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources fi ==== *bwark* Wenn ich das richtig lese wird die ~/.Xresources eben immer geladen (per -merge, Vorgaben aus /etc/X11/Xresources und den app-defaults dabei überschreibend, aber nix löschend), und zwar nach der ggfs. ebenfalls existierenden ~/.Xdefaults, und dabei ggfs. die ~/.Xdefaults überschreibend. Mit nem Testuser/Testsystem: $ echo "foo*bar: 0" >> /etc/X11/Xresources $ echo "foo*bar: 1" > ~/.Xdefaults $ echo "foo*bar: 2" > ~/.Xresources Obiges scriptfragment aus der xinitrc.common ausführen und gucken: $ xrdb -query | grep foo Oder so ... ;) Ich hab mich jedenfalls vor langem auf ~/.Xresources eingeschossen und es könnte sogar sein, daß das mit dem symlink ~/.Xdefaults -> ~/.Xresources mal von SUSE so angelegt wurde ... Apropos: X-resources sind viel zu wenig verwendet, dabei gibt's sogar nen graphischen Editor namens 'editres'. Und damit kann man z.B. einer perl/Tk GUI auch ne schicke Oberfläche verpassen ... (und dabei optional den User diese auch anpassen lassen)! Das wird dann allerdings doch etwas zu lang für diese Liste, bei Interesse könnt ich mal was auf paste.o.o raufladen oder in der -programming Liste mailen. -dnh --

Und die Hosen sind auf geheimnisvolle Weise am Hintern festgetackert, sonst würden sie nämlich runterfallen. -- Princess _DAS_ ist die Lösung. Piercing statt Hosenträger! -- R. Schwentker -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Davi, hallo Roman! Erstmal vielen Dank für die ausführlichen Infos und Anmerkungen. Am 28.10.2014 um 08:12 Uhr schrieb Roman Fietze:

On Mon, 27.10.2014 12:54:29 David Haller wrote:

...

Das gehört in ~/.Xresources rein

Dann muss es jeder User getrennt einstellen. Auch /etc/skel/ ist da fuer mich keien Loesung, denn dann bekommt es nur jeder neu angelegte User.

Sehe ich auch so.

...

Achso, und systemweit gehört's nach /etc/X11/Xresources.

Exakt. Wenn schon, denn schon. Allerdings gehoert das ja xinit, und dann bekomme ich Updates davon ebenfalls nicht mehr (so einfach) mit. Da ist mir persoenlich schon lieber ich zerlege mir /usr/share/X11/app-defaults/XOsview. Nennt sich "bending the rules".

XOsview dürfte aber bei einem update von xosview auch überschrieben werden. Kommen da seltener die updates als bei xinit? Ansonsten ist es wohl egal. Viele Grüße Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 27. Oktober 2014 11:22 schrieb Christian Meseberg :

Wo müsste ich drehen, um die Temperaturanzige zu sehen?

man xosview such mal nach coretemp Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org