Linux Projektvorstellung: TLP – Linux Stromsparen

[linrunner]

Nachdem im Forum öfters nachgefragt wird, wie man Linux die Feinheiten des Stromsparens beibringt, habe ich mich vor einiger Zeit entschlossen, meine Skriptsammlung in eine allgemein benutzbare Form zu bringen. Das Ergebnis möchte ich Euch an dieser Stelle vorstellen.

Dokumentation ist auf der offiziellen Website https://linrunner.de/tlp/ zu finden (die Infos in unserem Wiki werden von mir nicht mehr gepflegt und sind veraltet).

Fragen und Probleme einfach hier im Thread posten.

Für die erste Analyse benötige ich bitte stets den kompletten Output von

sudo tlp-stat

Anmerkung: ich fordere oft in der weiteren Analyse Teilausgaben an - das sollt ihr jedoch nicht selbstständig tun! Immer zuerst die vollständige Ausgabe.

Bitte auch die FAQ beachten!

Rückmeldungen der Art "alles funktioniert" sind natürlich auch gern gesehen ...

 

[chalee]

Cool! Dann bin ich nicht alleine damit.. ;-)

- - - Beitrag zusammengeführt - - -

...habe das gleiche Problem!
Ich benutze Linux Mint 17.3, MATE, 64bit (Ubuntu 14.04):



Beim upgrade von tlp auf Version 1.1-1 (~trusty) wird zwar tlp
erfolgreich aktualisiert - beim nachfolgenden tlp-rdw-upgrade gibt es
aber die gleiche Fehlermeldung (und Abbruch) wie bei User nsteinbach!

Weder mit Synaptik noch mit dem Termial-upgrade bekomme ich tlp-rdw
aktualisiert und es bleibt bei V. 1.0-1 (~trusty).

Ausserdem gibt synaptik/terminal teilweise die Ausgabe, das tlp-rdw
inkonstistent wäre und erstmal neu installiert werden soll, bevor es
entfernt werden kann, WENN ich es versuche zu deinstallieren.
Ein Neuinstall bricht aber wieder mit obriger Fehlermeldung ab.

Auch ein erneutes herunterladen von tlp-rdw.deb bringt das gleiche Ergebnis.

Was mir noch auffiel: bei tlp kann ich mit synaptic die (vorherige) Version erzwingen - bei tlp-rdw geht das aber (nicht) mehr.

Bis jetzt hatte ich in 2 Jahren nie wirkliche Probleme mit Paketen,
Abhängigkeiten oder tlp!

Ich habe die letzten Wochen auch nichts an meinem System verändert.

Nur das obligatorische Kernelupgrade wegen Meltdown-/Spectre-Patches auf
Kernel 4.4.0-111 könnte evtl. den Fehler verursacht haben?
Oder ein fehlerhaftes deb-Packet?

Das mit dem Kernel werde ich gleich mal testen und einen älteren laden,
glaube aber nicht, das dies der Grund ist.
Bisher hat sich tlp auch mit jedem Kernelupgrade gut "vertragen".

Probiert habe ich auch die Standardprozedur bei defekten Paketen
und/oder Abhängigkeiten:

sudo dpkg --configure -a

sudo apt-get install -f

Leider ohne Erfolg!

Hier mal mehr Informatinen über meine Terminalausgaben und Fehlermeldungen:

sudo apt-get install -f
[sudo] password for userx:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  tlp tlp-rdw
Empfohlene Pakete:
  smartmontools linux-tools
Die folgenden NEUEN Pakete werden installiert:
  tlp
Die folgenden Pakete werden aktualisiert (Upgrade):
  tlp-rdw
1 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 69,0 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 338 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Vormals nicht ausgewähltes Paket tlp wird gewählt.
(Lese Datenbank ... 436131 Dateien und Verzeichnisse sind derzeit
installiert.)
Vorbereitung zum Entpacken von .../tlp_1.1-1~trusty_all.deb ...
Entpacken von tlp (1.1-1~trusty) ...
Vormals nicht ausgewähltes Paket tlp-rdw wird gewählt.
Vorbereitung zum Entpacken von .../tlp-rdw_1.1-1~trusty_all.deb ...
dpkg-maintscript-helper: error: last version is missing
dpkg: Fehler beim Bearbeiten des Archivs
/var/cache/apt/archives/tlp-rdw_1.1-1~trusty_all.deb (--unpack):
 Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurück
dpkg-maintscript-helper: error: last version is missing
dpkg: Fehler beim Aufräumen:
 Unterprozess neues post-removal-Skript gab den Fehlerwert 1 zurück
Trigger für ureadahead (0.100.0-16) werden verarbeitet ...
ureadahead will be reprofiled on next reboot
Trigger für man-db (2.6.7.1-1ubuntu1) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/tlp-rdw_1.1-1~trusty_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ist das Problem/der Fehler schon bekannt?

Über eine Lösung würde ich mich sehr freuen..

LG,
chalee

sudo tlp-stat
--- TLP 1.1 --------------------------------------------

+++ Configured Settings: /etc/default/tlp
TLP_ENABLE=1
TLP_DEFAULT_MODE=AC
TLP_PERSISTENT_DEFAULT=0
DISK_IDLE_SECS_ON_AC=0
DISK_IDLE_SECS_ON_BAT=2
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=60
CPU_HWP_ON_AC=balance_performance
CPU_HWP_ON_BAT=balance_power
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
NMI_WATCHDOG=0
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=power
DISK_DEVICES="sda sdb"
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
SATA_LINKPWR_ON_AC="med_power_with_dipm max_performance"
SATA_LINKPWR_ON_BAT="med_power_with_dipm min_power"
AHCI_RUNTIME_PM_TIMEOUT=15
PCIE_ASPM_ON_AC=performance
PCIE_ASPM_ON_BAT=powersave
RADEON_POWER_PROFILE_ON_AC=high
RADEON_POWER_PROFILE_ON_BAT=low
RADEON_DPM_STATE_ON_AC=performance
RADEON_DPM_STATE_ON_BAT=battery
RADEON_DPM_PERF_LEVEL_ON_AC=auto
RADEON_DPM_PERF_LEVEL_ON_BAT=auto
WIFI_PWR_ON_AC=off
WIFI_PWR_ON_BAT=on
WOL_DISABLE=Y
SOUND_POWER_SAVE_ON_AC=0
SOUND_POWER_SAVE_ON_BAT=1
SOUND_POWER_SAVE_CONTROLLER=Y
BAY_POWEROFF_ON_AC=0
BAY_POWEROFF_ON_BAT=0
BAY_DEVICE="sr0"
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
USB_AUTOSUSPEND=1
USB_BLACKLIST_BTUSB=0
USB_BLACKLIST_PHONE=0
USB_BLACKLIST_PRINTER=1
USB_BLACKLIST_WWAN=1
RESTORE_DEVICE_STATE_ON_STARTUP=0

+++ System Info
System         = LENOVO ThinkPad T410
BIOS           = 6IET85WW (1.45 )
Release        = Qiana Studio 17.3 Xi (~LinuxMint 17.3 Rosa/Ubuntu 14.04
Trusty)
Kernel         = 4.4.0-111-lowlatency #134~14.04.1-Ubuntu SMP PREEMPT
Mon Jan 15 16:35:19 UTC 2018 x86_64
/proc/cmdline  = BOOT_IMAGE=/boot/vmlinuz-4.4.0-111-lowlatency
root=UUID=83658b14-fd42-4ffa-9eb2-3a40932192c4 ro quiet splash vt.handoff=7
Init system    = upstart
Boot mode      = BIOS (CSM, Legacy)

+++ TLP Status
State          = enabled
Last run       = 16:26:08,  14900 sec(s) ago
Mode           = AC
Power source   = AC

+++ Processor
CPU model      = Intel(R) Core(TM) i5 CPU       M XXXX  @ 2.40GHz

 

[linrunner]

Hi,

die Pakete Version 1.1-1~trusty im PPA sind leider kaputt. Asche auf mein Haupt.

Ich habe die korrigierte Version 1.1-2~trusty hochgeladen. leider ist der Build noch nicht gelaufen. Bitte wartet bis morgen früh und probiert dann nochmal ein Update EDITH: Pakete sind bereit, bitte einfach updaten

apt-get update && apt-get dist-upgrade

 

[nsteinbach]

Super, danke für die Info! Dann werde ich es morgen aktualisieren und dann läuft wieder alles, wie man es von TLP gewohnt ist.

Toller Service, vielen dank!

 

[chalee]

yea. von mir auch: MERCI!

 

[linrunner]

Hi @all,

die neue Version 1.1 ist ja schon am 24.01.2018 erschienen, wie Ihr an obigem Problem sehen konntet. Nun ist auch die deutsche Doku im Wiki angepasst. Die Neuerungen findet Ihr wie immer im Changelog.

EDITH: 1.1-Pakete sind mittlerweile verfügbar für Arch Linux, Debian (Unstable, Testing sowie Stretch, Jessie via Backports), OpenSUSE (Tumbleweed), Ubuntu (18.04 bzw. PPA). Weitere siehe Repology. Fedora ist noch beim Maintainer in Arbeit.

Have fun!

 

[harpo]

Ich habe vor kurzem bei mir eine Unstimmigkeit bei der neuen Funktion CPU_HWP_ON festgestellt. Zuerst fiel mir dies unter TLPUI auf und ich vermutete zunächst einen Anzeigefehler hier. Denn Obwohl ich hier die Standardeinstellungen habe:

CPU_HWP_ON_AC=balance_performance
CPU_HWP_ON_BAT=balance_power

wird mir in TLPUI bei ...BAT lediglich "power" angezeigt. Jedoch ist dies auch bei der Ausgabe von TLP stat auffälig. Hier sehen bei Akku-Betrieb die einzelnen Zeilen für jeden Kern/Thread so aus:

/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver    = intel_pstate
/sys/devices/system/cpu/cpu5/cpufreq/scaling_governor  = powersave
/sys/devices/system/cpu/cpu5/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu5/cpufreq/scaling_min_freq  =   800000 [kHz]
/sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq  =  2600000 [kHz]
/sys/devices/system/cpu/cpu5/cpufreq/energy_performance_preference = balance_power
/sys/devices/system/cpu/cpu5/cpufreq/energy_performance_available_preferences = default performance balance_performance balance_power power

Während dann die darauffolgende Ausgabe für jeden Kern/Thread dies zeigt:

x86_energy_perf_policy.cpu0                            = power 
x86_energy_perf_policy.cpu0                            = HWP_REQ: min
x86_energy_perf_policy.cpu0                            = HWP_CAP: low

Bei Netzbetrieb wird in beiden Ausgaben korrekt "balance_performance" angezeigt.

System ist ein T460p unter Kubuntu 16.04.3 mit Kernel 4.13.0-32-generic.

Woran kann das liegen? TLP, Kernel oder etwas anderes im OS? Ein Fehler in der Hardware wird es doch wohl nicht sein?!
Ich meine auch, dass das vor einiger Zeit noch korrekt angezeigt wurde! Also "balance_power" auch in TLPUI und der Zeile x86_energy_perf_policy.cpux.

 

[linrunner]

Moin harpo,

bitte immer (zusätzlich) die gesamte Ausgabe zeigen, am besten über einen (anmeldungsfreien) Paste-Service deiner Wahl. In deinem speziellen Fall benötige ich zusätzlich die kpl. Ausgabe von

sudo x86_energy_perf_policy

um den tlp-stat-Parser anpassen zu können.

Zu deiner eigentlichen Frage: es sind einfach zwei verschiedene Einstellungen

• CPU_HWP_ON_AC/BAT – schreibt in energy_performance_preference
• ENERGY_PERF_POLICY_ON_AC/BAT – ruft x86_energy_perf_policy auf

und sowohl die Bezeichnungen als auch die gültigen Strings sind verwirrend ähnlich. Für ENERGY_PERF_POLICY_ON_AC/BAT wurden sie kürzlich angepasst (siehe Commit). Sie sind übrigens im Netzbetrieb unterschiedlich. Wenn Du genau hinschaust, ist nämlich balance_power != balance-power.

In Issue der mich damals auf HWP aufmerksam gemacht hat, schrieb jemand:

If I understand correctly, this option should override x86_energy_perf_policy, but in 4.10 it looks like they're independent

Im Moment sieht es noch nicht so aus, als ob die beiden Features zusammengeführt werden/wurden. Vielleicht hast Du Zeit etwas zu recherchieren? Ich wäre für Infos dankbar, da ich keine passende Hardware habe. Siehe auch intel_pstate.

ps. zu TLPUI kann ich nicht helfen.

 

[harpo]

Hi linrunner,

besten Dank für Deine Antwort!

Zu deiner eigentlichen Frage: es sind einfach zwei verschiedene Einstellungen

CPU_HWP_ON_AC/BAT – schreibt in energy_performance_preference
ENERGY_PERF_POLICY_ON_AC/BAT – ruft x86_energy_perf_policy auf


und sowohl die Bezeichnungen als auch die gültigen Strings sind verwirrend ähnlich. Für ENERGY_PERF_POLICY_ON_AC/BAT wurden sie kürzlich angepasst (siehe Commit). Sie sind übrigens im Netzbetrieb unterschiedlich. Wenn Du genau hinschaust, ist nämlich balance_power != balance-power.

:facepalm: Das hätte mir natürlich auch auffallen können! Bzw. habe ich die Änderungen im changelog zur aktuellen Version und der angepassten Einstellungsseite im Wiki auch gelesen und sogar bewusst die Einstellungen für ENERGY_PERF_POLICY_ON_AC auf balance-performance und für ENERGY_PERF_POLICY_ON_BAT auf power gesetzt. Daher wurde also doch alles korrekt den gesetzten Einstellungen in /etc/default/tlp entsprechend in der Ausgabe von tlp stat angezeigt.

Habe jetzt die Einstellung für BAT auch auf balance-power gesetzt und wird auch korrekt wiedergegeben. Allerdings: Auch hier kurios das Verhalten in TLPUI, wird doch auch hier lediglich power statt balance-power angezeigt. Scheint also ein Anzeigefehler in TLPUI zu sein in beiden Fällen? Man kann jedoch über die GUI die Einstellungen korrekt setzen, diese werden wie angegeben in die Datei geschrieben und über stat auch so wiedergeben. In der GUI werden sie auch sowohl für CPU_HWP als auch für ENERGY_PERF_POLICY korrekt angezeigt, eben bis auf jeweils balance_/-power, da wird in beiden Fällen nur power angezeigt. Bei wie gesagt korrekter Anzeige/Ausgabe in tlp stat und der Datei.

Werde das mal in dem entsprechenden Thread zu TLPUI posten. Da hatte ich auch schon mal die etwas missverständliche Umsetzung der WOL-Einstellung angemerkt, was aber reaktionslos blieb. Eventuell schaut der Entwickler hier nicht mehr rein? Besser (auch) bei Github posten?

Da für mich die Frage vorerst geklärt ist, möchtest Du die Ausgaben dennoch?

- - - Beitrag zusammengeführt - - -

Aber noch eine andere Sache, die mir aufgefallen ist: Die Wifi-Powersafe-Einstellung spinnt bei mir (bzw. nur die Anzeige?). Meine Einstellung ist:

WIFI_PWR_ON_AC=off
WIFI_PWR_ON_BAT=on

Wenn der Rechner am Netzkabel startet wird nach tlp stat folgendes ausgegeben:

+++ Wireless
bluetooth = none (no device)
wifi      = on
wwan      = none (no device)

wlp3s0(iwlwifi)               : wifi, connected, power management = on

Das ändert sich erst, wenn ich entweder das Netzkabel abziehe und wieder einstecke oder manuell tlp start im Terminal eingebe. Dann wird auch am Netzkabel korrekt =off angezeigt. Hier die komplette Ausgaben von tlp stat:

Am Netzteil gestartet: https://pastebin.com/D58hUmLC
Nach Abziehen des Kabels: https://pastebin.com/NfhcDpEV
Nach wieder Anstecken: https://pastebin.com/wtrp7NQf

 

[linrunner]

@harpo: es ist auf die Dauer mühsam, die schon im Startpost und der Doku genannten Ausgaben erneut anzufordern und schliesslich noch auf die Frage zu antworten, ob sie wirklich gebraucht werden.
:Oldtimer:

Unabhängig von der konkreten Fragestellung, dienen mir die Ausgaben immer auch zur laufenden Qualitätssicherung von TLP. In deinem Fall stimmt etwas nicht mit den x86_energy_perf_policy.cpu* Zeilen, daher benötige ich zusätzlich

sudo x86_energy_perf_policy

Deine Fragestellung zu WiFi Powersave wird übrigens in der FAQ behandelt .

 

[harpo]

es ist auf die Dauer mühsam, die schon im Startpost und der Doku genannten Ausgaben erneut anzufordern und schliesslich noch auf die Frage zu antworten, ob sie wirklich gebraucht werden.

Sorry, ich hielt das "Problem" für gelöst bzw. nun doch für einen Anzeigefehler in TLPUI und daher die Ausgaben für nicht mehr nötig! :whistling: Aber hier sind sie:

Am Netzteil:

cpu0: EPB 4                                                                                                    
cpu0: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0                                      
cpu0: HWP_CAP: low 1 eff 8 guar 26 high 35                                                                     
cpu1: EPB 4                                                                                                    
cpu1: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0                                      
cpu1: HWP_CAP: low 1 eff 8 guar 26 high 35                                                                     
cpu2: EPB 4                                                                                                    
cpu2: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0                                      
cpu2: HWP_CAP: low 1 eff 8 guar 26 high 35                                                                     
cpu3: EPB 4                                                                                                    
cpu3: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0
cpu3: HWP_CAP: low 1 eff 8 guar 26 high 35
cpu4: EPB 4
cpu4: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0
cpu4: HWP_CAP: low 1 eff 8 guar 26 high 35
cpu5: EPB 4
cpu5: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0
cpu5: HWP_CAP: low 1 eff 8 guar 26 high 35
cpu6: EPB 4
cpu6: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0
cpu6: HWP_CAP: low 1 eff 8 guar 26 high 35
cpu7: EPB 4
cpu7: HWP_REQ: min 8 max 35 des 0 epp 128 window 0x0 (0*10^0us) use_pkg 0
cpu7: HWP_CAP: low 1 eff 8 guar 26 high 35

Auf Akku:

cpu0: EPB 8
cpu0: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu0: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu1: EPB 8
cpu1: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu1: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu2: EPB 8
cpu2: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu2: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu3: EPB 8
cpu3: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu3: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu4: EPB 8
cpu4: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu4: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu5: EPB 8
cpu5: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu5: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu6: EPB 8
cpu6: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu6: HWP_CAP: low 1 eff 9 guar 26 high 35
cpu7: EPB 8
cpu7: HWP_REQ: min 8 max 11 des 0 epp 192 window 0x0 (0*10^0us) use_pkg 0
cpu7: HWP_CAP: low 1 eff 9 guar 26 high 35

Hm, was liegt denn jetzt hier nióch im Argen bei mir? Wie schon erwähnt, ich hatte jetzt ENERGY_PERF_POLICY_ON_BAT= von power auf balance-power umgestellt. Sowohl schon bei den tlp stat-Ausgaben aus meinem letzten Post als auch bei denen von x86_energy_perf_policy hier.

Übrigens ist mir gerade aufgefallen, dass auf der Einstellungsseite im Wiki hier bei den erlaubten Werten zwischen "perfprmace" und "default" "balanc-powersafe" steht! Sollte das nicht eigenltlich "balance-performace" sein?

Deine Fragestellung zu WiFi Powersave wird übrigens in der FAQ behandelt .

Oh je, da hätte ich natürlich auch mal schauen können! Danke!

 

[linrunner]

@harpo: Wiki korrigiert, Danke. Die Zeilen cpu*: HWP_... muss ich herausfiltern bzw. die Bedeutung nachschlagen.

EDITH fragt, ob Du das geänderte tlp-stat mal ausprobieren und die Ausgabe von tlp-stat -p zeigen möchtest?

 

[harpo]

Die Zeilen cpu*: HWP_... muss ich herausfiltern bzw. die Bedeutung nachschlagen.

Darf man fragen wieso? Erstmal nur, weil Dir die Bedeutung nicht ganz klar ist? (Mir schon gar nicht!) Ich hab davon keinen Schimmer, bin nur 'n dummer Geisteswissenschaftler...

EDITH fragt, ob Du das geänderte tlp-stat mal ausprobieren und die Ausgabe von tlp-stat -p zeigen möchtest?

Würde ich für die EDITH gerne tun, wenn sie mir noch sagt wie! (Siehe letzten Satz mit dem Schimmer.)

 

[woleska]

Einfach im Terminal "sudo tlp stat -p" und dann dein Passwort eingeben und die Ausgabe dann hier posten, wenn du möchtest.

 

[harpo]

Einfach im Terminal "sudo tlp stat -p" und dann dein Passwort eingeben und die Ausgabe dann hier posten, wenn du möchtest.

Nee, dazu muss doch erstmal die Änderung in tlp-stat vorgenommen werden!

Meine Edit fragt dazu den linrunner: Einfach die Zeile 618 in /usr/bin/tlp-stat entsprechend der Änderung in Deinem GitHub-Link ändern?

Die Edit hat das jetzt einfach mal so gemacht, wie sie gefragt hat. Und das kam dabei raus:

Auf AC: https://pastebin.com/TzBq6xuU
Auf BAT: https://pastebin.com/LPu2FDZR

Sieht ganz ok aus, oder?

 

[linrunner]

@harpo: passt, Danke.

EDITH sagt: mit den HWP-Zeilen muss ich mich erst noch befassen, komme ggf. zwecks Testen auf dich zu.

 

[harpo]

EDITH sagt: mit den HWP-Zeilen muss ich mich erst noch befassen, komme ggf. zwecks Testen auf dich zu.

Jo, mach. Gerne.

 

[linrunner]

1.1-Pakete sind mittlerweile verfügbar für Arch Linux, Debian (Unstable, Testing sowie Stretch, Jessie via Backports), OpenSUSE (Tumbleweed), Ubuntu (18.04 bzw. PPA). Weitere siehe Repology. Fedora ist noch beim Maintainer in Arbeit.

 

[chalee]

Hallo Linrunner! Ich habe folgendes Problem, das ich nur durch Zufall bemerkte:
seit einiger Zeit (tlp-update, Kernel-upgrade) zeigt mir TLP oder Linux Mint BAt-Mon nicht mehr den Cycle-Count von meinem Akku an!
Ich benutze einen T410 mit Linux Mint 17.3, MATE, 64bit und hatte tlp und tp-smapi schon längere Zeit nicht mehr benutzt, bzw. es im Hintergrund seinen Dienst machen lassen. Ich erinnere mich aber, das der batterie-CYCLE-COUNT in der Vergangenheit angezeigt wurde.

Ich habe nach einem Kernelupgrade auf 4.4.0-116 wie immer auch tlp,tlp-rdw, tp-smapi-dkms reinstalliert, damit die Kernelmodule richtig geladen werden.
Nun scheint tp-smapi aber nach dem Kernelupgrade nicht mehr richtig geladen zu werden, was ich auch nur durch ein zufälliges:

sudo tlp-stat --battery
[sudo] password for user:
--- TLP 1.1 --------------------------------------------

+++ ThinkPad Battery Features
tp-smapi = inactive (kernel module 'tp_smapi' load error)
tpacpi-bat = inactive (unsupported hardware)

+++ Battery Status
/sys/class/power_supply/BAT0/manufacturer = SANYO
/sys/class/power_supply/BAT0/model_name = 42T4794
/sys/class/power_supply/BAT0/cycle_count = (not supported)
/sys/class/power_supply/BAT0/charge_full_design = 4400 [mAh]
/sys/class/power_supply/BAT0/charge_full = 4400 [mAh]
/sys/class/power_supply/BAT0/charge_now = 4398 [mAh]
/sys/class/power_supply/BAT0/current_now = 0 [mA]
/sys/class/power_supply/BAT0/status = Unknown

Charge = 100.0 [%]
Capacity = 100.0 [%]

heraus fand.

Habe dann mal nach den Anleitungen des tlp-wikis/faqs versucht das Kernelmodule manuell zu laden, bekomme aber immer nur die Meldung:

sudo modprobe -v tp_smapi
[sudo] password for user:
insmod /lib/modules/4.4.0-116-lowlatency/extra/thinkpad_ec.ko
modprobe: ERROR: could not insert 'tp_smapi': Exec format error

Kann es sein, das meine tp-smapi-dkms-Version (0.41-1) mit dem neuen Kernel nicht harmoniert?
Kann ja auch sein, das die Spectre-/Meltdown-Kernel-Patch-Orgien da z.Zt. was blockieren oder nicht mehr mit tp-smapi kompatibel sind!?
Und ich nur ein upgrade abwarten muss?

Aber vielleicht weißt du (oder jemand anderes im Forum) ja auch was zu tun ist?

LG, chalee

 

[RomanX]

Moin
Bitte mal die Ausgabe der folgenden Befehle posten.

uname -a
modinfo thinkpad_ec
modinfo tp_smapi

 

[chalee]

xxx

uname -a
4.4.0-116-lowlatency #140~14.04.1-Ubuntu SMP PREEMPT Fri Feb 16 10:10:25 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

~ > modinfo thinkpad_ec
filename: /lib/modules/4.4.0-116-lowlatency/extra/thinkpad_ec.ko
license: GPL
version: 0.41
description: ThinkPad embedded controller hardware access
author: Shem Multinymous
srcversion: XYXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
depends:
vermagic: 4.4.0-116-lowlatency SMP preempt mod_unload modversions
parm: force_io:Force IO even if region already reserved (0=off, 1=on) (bool)

~ > modinfo tp_smapi
filename: /lib/modules/4.4.0-116-lowlatency/extra/tp_smapi.ko
license: GPL
version: 0.41
description: ThinkPad SMAPI Support
author: Shem Multinymous
srcversion: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
depends: thinkpad_ec
vermagic: 4.4.0-116-lowlatency SMP preempt mod_unload modversions
parm: debugebug level (0=off, 1=on) (int)

Also mit lowlatency-kernel 4.4.0-72 und einer älteren tlp-Version wurde tp-smapi noch korrekt geladen und auch der Batteriestatus und CycleCount ausgegeben, (was jetzt komischerweise nicht mehr geht, da tp-smapi-modul nicht korrekt geladen wird!?) ! Habe da noch einen alten Screenshot von 2017 gefunden.
Leider habe ich die alte tp-smapi-Version nicht mehr als .deb und kann eine ältere Version via Synaptik komischerweise auch nicht erzwingen, da das Feld ausgegraut erscheint.
Ältere tlp-debs habe ich zum testen da.

Die generic-headers habe ich auch installiert. Trotzdem: Tlp ist enabled und arbeitet auch - aber tp-smapi wird nicht korrekt geladen und schränkt damit den gebrauch von tlp ein...