lm_sensors update - Stromsparen und Hardwarewerte auslesen funktioniert nichtmehr - Notebooks & Mobile Geräte

Anfänger

Montag, 5. Juli 2010, 14:30

lm_sensors update - Stromsparen und Hardwarewerte auslesen funktioniert nichtmehr

Hallo,

hab daneulich ein lm_sensors update gemacht. In den Meldungen danach stand, dass er das Makefile meines Kernels nicht finden konnte...hatte die Kernelsourcen auf Grund akuten Speichermangels schon gelöscht.

Habe nun einen neune Kernel (2.6.32-r7) kompiliert, hier den für meine Intel Core2Mobile CPU benötigte Coretemp direkt reinkompiliert.

Darauf hin den Kernel gestartet, lm_sensors neu gemerget und sensors-detect durchlaufen lassen. Was mich hier wundert: er listet meinen Chipsatz (ICH7) nicht auf, ist das richtig so?
Die Treiber für ICH10 ind ebenfalls in den Kernel kompiliert.

Quellcode

sensors-detect
# sensors-detect revision 5818 (2010-01-18 17:22:07 +0100)
# System: Hewlett-Packard HP Compaq nx9420 (RH457ET) (laptop)
# Board: Hewlett-Packard 309F

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): y
Silicon Integrated Systems SIS5595...                   	No
VIA VT82C686 Integrated Sensors...                      	No
VIA VT8231 Integrated Sensors...                        	No
AMD K8 thermal sensors...                               	No
AMD Family 10h thermal sensors...                       	No
AMD Family 11h thermal sensors...                       	No
Intel Core family thermal sensor...                     	Success!
	(driver `coretemp')
Intel Atom thermal sensor...                            	No
Intel AMB FB-DIMM thermal sensor...                     	No
VIA C7 thermal sensor...                                	No
VIA Nano thermal sensor...                              	No

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): y
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...               	No
Trying family `SMSC'...                                 	Yes
Found unknown chip with ID 0x2600
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...               	No
Trying family `SMSC'...                                 	Yes
Found unknown non-standard chip with ID 0x7a

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): y
Probing for `National Semiconductor LM78' at 0x290...   	No
Probing for `National Semiconductor LM79' at 0x290...   	No
Probing for `Winbond W83781D' at 0x290...               	No
Probing for `Winbond W83782D' at 0x290...               	No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): y
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `coretemp':
  * Chip `Intel Core family thermal sensor' (confidence: 9)

Warning: the required module coretemp is not currently installed
on your system. If it is built into the kernel then it's OK.
Otherwise, check http://www.lm-sensors.org/wiki/Devices for
driver availability.

No modules to load, skipping modules configuration.

Unloading i2c-dev... OK

Allerdings läuft mein PC nun fast dauernd auf 2,17GHz, anstatt auf 1Ghz runterzutakten. Ganz selten ist er für eine Sekunde mal bei 1,67GHz.

Top sagt: 5% CPU-Last.

Die Auslesung von Werten via Widgets tut seit dem auch nichtmehr, ich erhalte keinerlei Anzeigen mehr (komplett weg, nicht nur "0")
Dies betrifft:
-CPU-Lasten (Frequenzanzeige funktioniert)
- RAM/SWAP
- Netzwerk
-Temperaturen

Die Festplattenbelegung kann er noch anzeigen. Auch andere Programme (zB SysMonitor ) zeigt keine Werte an.
Uname -a liest auch die korrekte CPU aus:

	Quellcode
1	Linux zebra 2.6.32-gentoo-r7 #2 SMP Sun Jul 4 23:12:39 CEST 2010 i686 Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux

Interessanter Weise ist hier iwie die Uhr kaputt

der lm_sensors Daemon lässt sich nicht starten, da keine /etc/conf.d/lm_sensors existiert...allerdings legt sensors-detect ja anscheinend keine an?

Das Energieprofil ist auf Performance, er taktet auch bei Powersave etc... nicht herunter.

Hat jemand noch ein paar Ideen, woran das liegen könnte?
Fehlt mir irgendein Kernelmodul?
CPUFrequtils sind installiert, Daemon läuft, merge ich gerade nochmal neu...

Liebe Grüße,
niethitwo

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »niethitwo« (5. Juli 2010, 15:48)

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 3 470

2

Montag, 5. Juli 2010, 14:50

Hm, welche Hardware hast du denn ("lspci")? Was hast du sonst noch so im Kernel aktiviert?

Was verwirredn ist: einerseits sprichst du von den lm_sensors und dann wieder vom powermanagement (frequency settings), was ja nicht gleich dasselbe ist.

Irgendwas anders als in http://en.gentoo-wiki.com/wiki/Lm_sensors und http://www.gentoo.org/doc/en/power-management-guide.xml

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

3

Montag, 5. Juli 2010, 15:58

Quellcode

lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]
02:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
02:06.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
02:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
02:06.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
02:06.4 Communication controller: Texas Instruments PCIxx12 GemCore based SmartCard controller
08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5753M Gigabit Ethernet PCI Express (rev 21)
10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Die ACPI Sachen sind größtenteils im Kernel aktiviert, acpidals auch cpufreqd ist auch gestartet.
Manuelles setzen der CPU Frequenz via cpufreq-set gibt keine Fehlermeldung, ändert allerdings auch nichts

Wieso ich das in eine Schublade schmeiß: es tut seit dem lm_sensors update beides nicht mehr.

Könnten noch iwechle config Files helfen?

Ich hab das Gefühl, er bekommt die Korrekten p-States nicht mehr ausgelesen?

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

4

Montag, 5. Juli 2010, 16:02

Hm.., ja du schmeißt hier scheinbar einige Funktionen unterschiedlicher Programme durcheinander.
Zu lm_sensors kann ich nicht viel beitragen, aber schau mal ob die diese Erkenntnis evt. weiterhilft.

Zu der CPU Frequenz Taktung:
Was sagt den

	Quellcode
1	$ cpufreq-info

?

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

5

Montag, 5. Juli 2010, 19:06

Quellcode

cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik  Brodowski 2004-2006
Bitte melden Sie Fehler an  cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: acpi-cpufreq
   Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0
   Hardwarebedingte Grenzen der Taktfrequenz: 1000 MHz - 2.17 GHz
   mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
   mögliche Regler: conservative, ondemand, powersave, userspace,  performance
  momentane Taktik: die Frequenz soll innerhalb 2.17 GHz  und 2.17 GHz.
                liegen. Der Regler "performance" kann  frei entscheiden,
                welche Taktfrequenz innerhalb  dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 2.17 GHz   (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 1:
   Treiber: acpi-cpufreq
  Folgende CPUs können nur gleichzeitig ihre  Frequenz variieren: 1
  Hardwarebedingte Grenzen der Taktfrequenz:  1000 MHz - 2.17 GHz
  mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz,  1.33 GHz, 1000 MHz
  mögliche Regler: conservative, ondemand,  powersave, userspace, performance
  momentane Taktik: die Frequenz  soll innerhalb 2.17 GHz und 2.17 GHz.
                liegen. Der  Regler "performance" kann frei entscheiden,
                welche  Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane  Taktfrequenz ist 2.17 GHz  (verifiziert durch Nachfrage bei der  Hardware).

so, das hilft mir schonmal weiter. Anscheinend überstimmt hier jemand das KDE-Energieschema und stellt dauerhaft auf den Kernelmode performance...und dieser scheint wohl nur Volllast zu beinhalten

Ich schau nochmal, ob ich iwo was im KDE Zentrum falsch eingestellt hab...vll hab ich ja iwas übersehen

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

6

Montag, 5. Juli 2010, 19:51

Na das schaut doch schon mal gut aus.
Ich vermute das dein gewünschter Governor "ondemand" ist, dieser regelt die möglichen Frequenzen je nach lasst.
Manuell könntest du ihn zb via

	Quellcode
1	# cpufreq-set -g ondemand

setzen.

Wenn du das ganze von KDE setzen lassen möchtest, dann sollte im aktuellen kde-4.4.*
unter Systemeinstellungen --> Erweitert --> Energieverwaltung
deine gewünschten Einstellungen zu setzen sein.

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

7

Montag, 5. Juli 2010, 19:55

jupp, hab mittlerweile damit rumgespielt und leider agiert nichts wie geplant:

In KDE war im performance-Profil schon CPUFrequenz auf "dynamisch" geschaltet, trotzdem wurde von cpufreq der performance governor verwendet.

Also hab ich mal manuell auf den ondemand governor umgeschaltet:

Quellcode

cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: acpi-cpufreq
  Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0
  Hardwarebedingte Grenzen der Taktfrequenz: 1000 MHz - 2.17 GHz
  mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  mögliche Regler: conservative, ondemand, powersave, userspace, performance
  momentane Taktik: die Frequenz soll innerhalb 2.17 GHz und 2.17 GHz.
                	liegen. Der Regler "ondemand" kann frei entscheiden,
                	welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 2.17 GHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 1:
  Treiber: acpi-cpufreq
  Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 1
  Hardwarebedingte Grenzen der Taktfrequenz: 1000 MHz - 2.17 GHz
  mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  mögliche Regler: conservative, ondemand, powersave, userspace, performance
  momentane Taktik: die Frequenz soll innerhalb 2.17 GHz und 2.17 GHz.
                	liegen. Der Regler "ondemand" kann frei entscheiden,
                	welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 2.17 GHz  (verifiziert durch Nachfrage bei der Hardware).

Man beachte die Zeile mit der aktuellen Taktik: er darf nicht runtertakten, obwohl er die richtigen Frequenzmöglichkeiten erkannt hat

Hab schon in der cpufreq.conf geschaut, dort sind allerdings die Bereiche in % wunderbar angegeben.

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

8

Montag, 5. Juli 2010, 20:35

Huhh... das ist in der tat ungewöhnlich...

Könntest du das ganze mal ohne X und KDE als root in einer Textkonsole testen,
würde dort das runtertakten mit dem ondemand governor klappen?

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

9

Montag, 5. Juli 2010, 20:44

Nope, gleicher output wie oben. :-(

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 3 470

10

Dienstag, 6. Juli 2010, 09:25

Hm, heist das, dass dein /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq nicht deinem /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq entspricht ... kannst du ersters mal schreiben?

Ändert das was?

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

11

Dienstag, 6. Juli 2010, 15:10

	Quellcode
1 2 3 4 5	$cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 2167000 $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 1000000

Ändern kann ich hier nichts, selbst root kann auf die Dateien nicht schreiben (Fsync Fehler bei vi ).

Aber das scheint dann ja wirklich der Fehelr zu sein....ist nur die Frage: wie beheben, und woher kommt's bei nem normalen emerge -NuD world?

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

12

Dienstag, 6. Juli 2010, 15:39

Zitat

Aber das scheint dann ja wirklich der Fehelr zu sein....ist nur die Frage: wie beheben, und woher kommt's bei nem normalen emerge -NuD world?

Ich vermute eher das mit dem neuen Kernel (Konfiguration) noch nicht wieder ganz passt,
sprich, ich würde die Kernel Konfiguration noch mal überprüfen und ggf den Kernel neu bauen.
ist da was zu finden?
wenn nein, dann hänge doch bitte hier mal ein dmesg mit an.

Könntest du noch mal dem bisherigen Kernel booten, würde es mit dem funken?

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

13

Dienstag, 6. Juli 2010, 16:23

Zitat von »josef.95«

Zitat

Aber das scheint dann ja wirklich der Fehelr zu sein....ist nur die Frage: wie beheben, und woher kommt's bei nem normalen emerge -NuD world?

Könntest du noch mal dem bisherigen Kernel booten, würde es mit dem funken?

War leider schon beim alten Kernel der Fall.

Ich verschieb mal mein mittlerweile riesiges /var/log/messages und schau, was er nach enem Reboot so alles reinschreibt und poste das.

EDIT: Log eines Startes mit neuem Kernel angehägt.
BTW: Kann man eigtl die Kernelmessages und Initmessages vom bootup iwo einsehen, bzw. iwo eine Log-Datei dafür angeben?

»niethitwo« hat folgende Datei angehängt:

messages.txt (122,06 kB - 2 mal heruntergeladen - zuletzt: 8. Juli 2010, 09:43)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »niethitwo« (6. Juli 2010, 16:34)

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

14

Dienstag, 6. Juli 2010, 21:13

	Quellcode
1	Jul 6 16:24:34 zebra cpufreqd: get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/C1C5/energy_full (No such file or directory)

Das ist doch schon mal ein guter Hinweis, den ich weiter verfolgen würde.

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

15

Dienstag, 6. Juli 2010, 21:20

Auf die Kürze find ich damit nichts, allerdings scheint es in letzterzeit v.a. mit dem 32er Kernel einige Probleme mit dem cpufreq-scaling zu geben...aber wieso tut es dann mit dem alten auch nicht? :huh:

was mich auch noch stutzen lässt:

	Quellcode
1	ls /sys/devices/system/cpu/cpufreq/ -la

liefert kein ergebnis, außer ./ und ../

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 5 568

16

Dienstag, 6. Juli 2010, 21:31

Würde bei mir zb so ausschauen

	Quellcode
1 2 3 4 5	# ls /sys/devices/system/cpu/cpufreq/ -la total 0 drwxr-xr-x 3 root root 0 Jul 6 21:27 . drwxr-xr-x 7 root root 0 Jul 6 16:22 .. drwxr-xr-x 2 root root 0 Jul 6 21:27 ondemand

Zitat

Auf die Kürze find ich damit nichts, allerdings scheint es in letzterzeit v.a. mit dem 32er Kernel einige Probleme mit dem cpufreq-scaling zu geben...aber wieso tut es dann mit dem alten auch nicht?

Lass dir Zeit...

Aber magst du es nicht mal mit einem 33er , oder evtl. besser, mit dem aktuellen 34er Kernel probieren?!
(sofern möglich)

Gentoo Dokumentation
GentooFreunde.org

Meine Jabber ID: kann via PN erfragt werden

Zum Seitenanfang

niethitwo

Anfänger

Beiträge: 32

17

Sonntag, 11. Juli 2010, 19:14

mir ist soeben aufgefallen, dass er während dem startup von KDE zeitweise 1,67GHz verwendet.

Dabei gibt cpufreq-info folgendes aus:

Quellcode

cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: acpi-cpufreq
  Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0
  Hardwarebedingte Grenzen der Taktfrequenz: 1000 MHz - 2.17 GHz
  mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  mögliche Regler: conservative, userspace, powersave, ondemand, performance
  momentane Taktik: die Frequenz soll innerhalb 1.67 GHz und 1.67 GHz.
                	liegen. Der Regler "performance" kann frei entscheiden,
                	welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.67 GHz.
analysiere CPU 1:
  Treiber: acpi-cpufreq
  Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 1
  Hardwarebedingte Grenzen der Taktfrequenz: 1000 MHz - 2.17 GHz
  mögliche Taktfrequenzen: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  mögliche Regler: conservative, userspace, powersave, ondemand, performance
  momentane Taktik: die Frequenz soll innerhalb 1.67 GHz und 1.67 GHz.
                	liegen. Der Regler "performance" kann frei entscheiden,
                	welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.67 GHz.

interessant, dass er anstatt über den governor die Taktrate über die in der Taktik angebebenen Takrate ändert...und dort dann eben nur noch 2,17Ghz reinschreibt

Ich wart einfach mal wenn ein neuer Kernel als stable markiert wird und schau, ob es danach vll wieder tut, wobei ich wenig Hoffnung hab...der alte hat ja auch plötzlich nicht mehr wie gewünscht funktioniert. :thumbdown:

Zum Seitenanfang

GentooForum.de

lm_sensors update - Stromsparen und Hardwarewerte auslesen funktioniert nichtmehr

lm_sensors update - Stromsparen und Hardwarewerte auslesen funktioniert nichtmehr

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Zitat

Zitat von »josef.95«

Zitat

Quellcode

Quellcode

Quellcode

Zitat

Quellcode

Ähnliche Themen

Häufig verwendete Suchbegriffe: