|
|
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| <div style="text-align: right;">
| | [[Bild:warning.png]] Die Inhalte dieser Seite waren veraltet und wurden deshalb vom TLP Autor entfernt. |
| [http://linrunner.de/en/tlp/docs/tlp-faq.html English version] | |
| </div>
| |
|
| |
|
| Hier werden häufig gestellte Fragen beantwortet und (Umgehungs-)Lösungen zu gängigen Problemen gegeben.
| | Bitte die [https://linrunner.de/tlp/faq offizielle Dokumentation (englisch)] verwenden. |
| | |
| = Installation und Konfiguration =
| |
| == Wie kann ich TLP auf einem Entwickler-Release meiner Distribution XY installieren ==
| |
| Die TLP-Pakete für neue Distributions-Release werden normalerweise rechtzeitig zu deren Releasetermin im TLP-Repository bereitgestellt. Möchte man TLP bereits vorher mit einer Alpha- oder Beta-Version testen, so kann man die Pakete für die Vorversion händisch mit dem jeweiligen Paketmanager installieren.
| |
| | |
| == Führt der Einsatz von TLP zusammen mit anderen Power Management Tools zu Konflikten? ==
| |
| Ja. Die simultane Verwendung eines anderen Tools bedeutet, dass TLPs Einstellungen von dem anderen Tool überschrieben werden (und umgekehrt). Das Ergebnis sind nicht vorhersagbare Resultate.
| |
| | |
| <u>Hinweise:</u>
| |
| * Powertop: siehe [[TLP_FAQ#Powertop|Powertop]].
| |
| * thermald: Aufgabe von thermald ist es, die Leistungsaufnahme zu begrenzen, bevor die Temperatur des Laptops in den kritischen Bereich kommt. TLP aktiviert hingegen generelle Einstellungen, um die Stromaufnahme speziell in Situationen geringer Last oder im Leerlauf zu optimieren. TLP steht nicht im Konfikt zu thermald.
| |
| * throttled: nur die dynamische HWP_Mode Einstellung von throttled stört die Aktionen von TLP. Möchte man sie verwenden, deaktiviert man die Funktion in TLP per CPU_ENERGY_PERF_POLICY_ON_AC="".
| |
| | |
| == Führt der Einsatz von TLP zu Konflikten mit den Energieeinstellungen meines Desktops? ==
| |
| Das hängt von der Einstellung ab. TLP:
| |
| * verändert nicht die Helligkeit von Bildschirm und Tastatur-Backlight → kein Konflikt,
| |
| * verändert nicht die Einstellungen für Suspend/Hibernate → kein Konflikt,
| |
| * aktiviert standardmäßig den Stromsparmodus für den WLAN-Adapter → möglicher Konflikt mit den KDE-Energieeinstellungen,
| |
| * (de-)aktiviert Funkadapter, wenn vom Benutzer konfiguriert → möglicher Konflikt mit den GNOME- bzw. KDE-Energieeinstellungen.
| |
| | |
| "Möglicher Konflikt" meint, dass die in TLP konfigurierte Einstellung von der Desktop-Energieeinstellung überschrieben werden kann (oder umgekehrt). Probleme mit der Systemstabilität sind dadurch nicht zu erwarten.
| |
| | |
| == Funktioniert TLP auch mit anderen Notebooks (nicht ThinkPads)? ==
| |
| TLP ist für alle Notebooks geeignet, einige [[TLP_FAQ#Akku|Features]] sind jedoch nur für ThinkPads verfügbar.
| |
| | |
| <u>Hinweis:</u> da der Programmautor nur über Testmöglichkeiten auf ThinkPads verfügt, sind Berichte und Fragen zu anderen Notebooks im [https://www.thinkpad-forum.de/thinkpad-software/linux-und-osx/84030-projektvorstellung-tlp---stromspareinstellungen-für-ubuntu/ Support-Thread] stets willkommen.
| |
| | |
| == Macht TLP Sinn auf neueren Laptops / mit neueren Linux-Versionen? ==
| |
| Ja, natürlich.
| |
| | |
| Über die Jahre wurden dem Linux Kernel viele Stromsparfunktionen hinzugefügt, aber nur ein Teil davon ist standardmäßig aktiviert. Es ist für die Kernelentwickler schwierig, Stromsparfunktionen vollständig für jegliche Hardware zu testen, daher bleiben sie für viele Treiber ausgeschaltet und es ist Aufgabe des Benutzers sie zu aktivieren.
| |
| | |
| Fazit: ein User Space Werkzeug wie TLP wird weiterhin benötigt, um alle verfügbaren Stromsparfunktionen zu aktivieren.
| |
| | |
| == Soll ich TLP in einer virtuellen Maschine installieren? ==
| |
| Nein. Es ist ineffektiv ein Power Management Tool innerhalb einer virtuellen Maschine (Guest) zu verwenden. TLP sollte stattdessen besser im Betriebssystem des VM-Hosts installiert werden.
| |
| | |
| == Wie kann ich die Einstellungen von TLP ändern? ==
| |
| Eine ausführliche Beschreibung aller Einstellungen findet sich im Artikel [[TLP_Einstellungen|TLP Einstellungen]].
| |
| | |
| == Überschreibt ein Upgrade von TLP meine Einstellungen? ==
| |
| Nein. Alle Paketverwaltungswerkzeuge achten darauf, vom Benutzer angepasste Konfigurationsdateien nicht ohne Rückfrage zu ersetzen bzw. sie erstellen zuvor eine Kopie.
| |
| | |
| == Wie übertrage ich meine Einstellungen beim Upgrade von 1.2.2 (oder älter) auf 1.3? ==
| |
| | |
| Zuerst sollte man [[TLP_Einstellungen#TLP_1.3_und_neuer|TLP Einstellungen]] lesen, um mehr über das neue Konfigurationsschema in 1.3 zu erfahren. Es gibt drei Migrationspfade:
| |
| | |
| === 1. 1:1 Übernahme ===
| |
| Das Format der Konfigurationsdatei hat sich nicht geändert, nur der Speicherort.
| |
| | |
| Nachdem man die ursprüngliche '''/etc/tlp.conf''' gesichert hat, kann man '''/etc/default/tlp''' nach '''/etc/tlp.conf''' kopieren.
| |
| | |
| <u>Nur Debian und Ubuntu:</u> falls '''/etc/default/tlp''' jemals bearbeitet wurde, wird die Datei beim Upgrade auf 1.3 automatisch nach '''/etc/tlp.conf''' verschoben. Die urspüngliche '''tlp.conf''' landet in '''/etc/tlp.conf.dpkg-new'''.
| |
| | |
| === 2. Neu beginnen mit '''/etc/tlp.conf''' ===
| |
| | |
| Hierzu gibt man einfach seine spezifischen Einstellungen in '''/etc/tlp.conf''' ein.
| |
| | |
| Anders als unter 1.2.2 und davor, sind alle Parameter in '''/etc/tlp.conf''' deaktiviert, das Kommentarzeichen '#' in der ersten Spalte muss für Parameter, die man ändern will, entfernt werden.
| |
| | |
| <u>Nur Debian und Ubuntu:</u> falls nötig verschiebt man '''/etc/tlp.conf.dpkg-new''' nach '''/etc/tlp.conf''' (siehe oben).
| |
| | |
| === 3. Neu beginnen mit einer Datei unterhalb von '''/etc/tlp.d/''' ===
| |
| | |
| Man erstellt eine neue Datei '''01-mytlp.conf''', indem man '''00-template.conf''' kopiert und seine spezifischen Einstellungen eingibt.
| |
| | |
| Der genaue Dateiname spielt keine Rolle, solange er auf '''.conf''' endet. Man kann seine Einstellungen auch in mehrere Dateien aufteilen.
| |
| | |
| <u>Nur Debian und Ubuntu:</u> falls nötig, verschiebt man '''/etc/tlp.conf.dpkg-new''' nach '''/etc/tlp.conf''' (siehe oben).
| |
| | |
| == TLP 1.2.2 und älter: Muss ich meine Einstellungen nach einem Update von TLP anpassen? ==
| |
| Nicht unbedingt. Bei der Weiterentwicklung von TLP wird darauf geachtet, dass alte Konfigurationsdateien weiterhin funktionieren. Neue Features bekommen – soweit möglich – sinnvolle interne Defaults, sodass sie auch ohne expliziten Eintrag in die Konfiguration wirken.
| |
| | |
| Allerdings sorgt das Paketupgrade nicht dafür, dass neue Features zur Konfigurationsdatei hinzugefügt werden. Wenn man also den Default für ein neues Feature anpassen möchte, kann man:
| |
| | |
| * die Einstellung händisch zur Konfiguration hinzufügen; oder
| |
| * alle eigenen Einstellungen in die temporäre, neue Konfigurationsdatei (Name hängt vom Paketwerkzeug ab) aufnehmen und und diese anschliessend an den [[TLP_Einstellungen#Einleitung|endgültigen Ort]] kopieren.
| |
| | |
| == Ich verwende den Network Manager nicht, wie kann ich in Ubuntu/Debian tlp ohne tlp-rdw installieren? ==
| |
| sudo apt install --no-install-recommends tlp
| |
| | |
| == Kann ich TLP auch mit Linux-Distributionen verwenden für die noch kein fertiges Paket existiert? ==
| |
| Prinzipiell ist es möglich den Source-Tarball bei [https://github.com/linrunner/TLP/tags GitHub] herunterzuladen, auszupacken mit
| |
| tar xfvz TLP-V.v.tar.gz
| |
| cd TLP-V.v
| |
| zu installieren (als root)
| |
| make install
| |
| make install-man
| |
| und die Services zu aktivieren (als root).
| |
| systemctl enable tlp.service
| |
| systemctl enable tlp-sleep.service # nur bis TLP 1.2.2
| |
| | |
| <u>Hinweis:</u> für das 'make install' sollte man die [https://localhost/linrunner/tlp/docs/tlp-developer-documentation.html#makefile Makefile-Optionen] an die verwendete Distribution anpassen.
| |
| | |
| ==Gibt es eine GUI zu TLP?==
| |
| Es existiert das separate Projekt [https://github.com/d4nj1/TLPUI TLPUI].
| |
| | |
| <u>Wichtig:</u> TLPUI ist noch nicht kompatibel mit TLP 1.3.
| |
| | |
| = Audio =
| |
| Bei Problemen mit der Soundausgabe im ''Akkubetrieb'' (Störungen, Klickgeräusche) kann man zur Eingrenzung in den [[TLP_Einstellungen#Audio|Einstellungen]] den Timeout erhöhen
| |
| SOUND_POWER_SAVE_ON_BAT=10
| |
| oder die Funktion ganz deaktivieren
| |
| SOUND_POWER_SAVE_ON_BAT=0
| |
| | |
| = Eingabegeräte =
| |
| == Warum funktioniert meine USB-Tastatur/-Maus nicht mehr? ==
| |
| TLP ist höchstwahrscheinlich nicht die Ursache, denn es nimmt standardmässig alle USB-Eingabegeräte (usbhid) vom Autosuspend aus.
| |
| | |
| == Bluetooth-Maus stockt oder verliert die Verbindung ==
| |
| Siehe [[TLP_FAQ#Bluetooth-Ger.C3.A4te_h.C3.A4ngen_oder_verlieren_die_Verbindung|Bluetooth]].
| |
| | |
| = Funkgeräte (Bluetooth, WLAN, WWAN) =
| |
| == Langsames oder instabiles WLAN im Akkubetrieb ==
| |
| Ursache: der Kerneltreiber implementiert den Stromsparmodus nicht korrekt.
| |
| | |
| Lösung: Stromsparmodus im Akkubetrieb deaktivieren
| |
| WIFI_PWR_ON_BAT=off
| |
| | |
| == WLAN Stromsparmodus ist an obwohl in der TLP-Konfiguration deaktiviert ==
| |
| Ursache: Konflikt mit NetworkManager.
| |
| | |
| Lösung: die Datei '''/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf''' löschen.
| |
| | |
| == Bluetooth-Geräte hängen oder verlieren die Verbindung ==
| |
| Ursache: nahezu alle internen und alle externen Bluetooth-Adapter sind USB-Geräte. Einige davon implementieren den Autosuspend-Modus nicht korrekt, was zu Problemen mit den verbundenen Bluetooth-Geräten führen kann oder auch das Pairing verhindert.
| |
| | |
| '''Lösungen'''
| |
| | |
| TLP 1.0 und höher:
| |
| USB_BLACKLIST_BTUSB=1
| |
| konfigurieren.
| |
| | |
| TLP 0.9 und niedriger: den USB-Bluetooth-Adapter identifizieren mit
| |
| tlp-stat -u | grep btusb
| |
| und die USB-ID zu USB_BLACKLIST hinzufügen. Die neue Einstellung aktivieren mit
| |
| sudo tlp usb
| |
| | |
| == Bluetooth wird beim Systemstart nicht deaktiviert ==
| |
| Wahrscheinliche Ursache: das Bluetooth-Applet der Desktop-Umgebung - oder eine andere installierte Software - aktiviert das Bluetooth-Gerät wieder, nachdem TLP es deaktiviert hat.
| |
| | |
| Lösung: Einstellung im betreffenden Applet deaktivieren oder das Applet ganz deaktivieren/entfernen. Informationen zu XFCE/Blueman finden sich im Artikel [https://winaero.com/blog/disable-bluetooth-auto-power-blueman/ "Deaktivieren der automatischen Bluetooth-Einschaltung in Blueman"] (englisch).
| |
| | |
| == Warum funktioniert das Wiederherstellen des Funkgerätezustands mit RESTORE_DEVICE_STATE_ON_STARTUP nicht? ==
| |
| Ursache: Konflikt mit anderen Einstellungen wie DEVICES_TO_DISABLE/ENABLE_ON_...
| |
| | |
| Lösung: RESTORE_DEVICE_STATE_ON_STARTUP=1 und DEVICES_TO_DISABLE/ENABLE_ON_... nicht gleichzeitig verwenden.
| |
| | |
| Ursache: systemd 209 (or higher) implementiert einen eigenen Weg (systemd-rfkill.service, siehe
| |
| [[TLP_Einstellungen#Funkger.C3.A4te_schalten|Funkgeräte schalten]]),
| |
| um die Schaltzustände beim Systemstart wiederherzustellen.
| |
| | |
| Lösung: RESTORE_DEVICE_STATE_ON_STARTUP=1 und das systemd-Feature nicht gleichzeitig verwenden.
| |
| | |
| == Warum aktiviert TLP nicht USB Autosuspend für meine integrierte WWAN (3G/UMTS, 4G/LTE, 5G) Karte? ==
| |
| Grund: einige Karten arbeiten nicht zuverlässig mit USB Autosuspend, daher schließt sie TLP (bis 1.1) standardmässig aus.
| |
| | |
| Lösung: um USB Autosuspend für WWAN(UMTS) zu erzwingen konfiguriert man
| |
| | |
| USB_BLACKLIST_WWAN=0
| |
| | |
| Siehe [[TLP_Einstellungen#USB|USB Einstellungen]].
| |
| | |
| = Grafik =
| |
| == Radeon ==
| |
| === Warum flackert mein Display beim Wechsel der Stromquelle kurz? ===
| |
| Grund ist die [[TLP_Einstellungen#Grafikkarten|automatische Umschaltung der Taktfrequenz bei Radeon-Karten]]. Auf Kosten eines höheren Stromverbrauchs, schafft folgende Einstellung Abhilfe:
| |
| RADEON_POWER_PROFILE_ON_AC=default
| |
| RADEON_POWER_PROFILE_ON_BAT=default
| |
| Je nach Karte bzw. Kernel hilft auch:
| |
| RADEON_POWER_PROFILE_ON_AC=performance
| |
| RADEON_POWER_PROFILE_ON_BAT=performance
| |
| | |
| == Kernelnachricht "*ERROR* radeon: ring 0 test failed" am Netzteil ==
| |
| Betroffene Hardware: Lenovo Ideapad 300 (Intel / Radeon Hybridgrafik).
| |
| | |
| Lösung: DPM ausschalten
| |
| RADEON_POWER_PROFILE_ON_AC=""
| |
| | |
| == Nvidia Optimus ==
| |
| === Warum hat mein Notebook einen extrem hohen Stromverbrauch? ===
| |
| Bei der Optimus-Hybridgrafik stecken im Notebook zwei Grafikeinheiten: eine von Intel auf dem Processor-Chip ("integrated", iGPU) und eine von Nvidia ("discrete", dGPU). Linux nutzt standardmäßig die Intel-Grafik, gleichzeitig ist die nicht genutzte Nvidia-Grafik eingeschaltet und verbraucht sehr viel Akkustrom weil kein Treiber geladen ist.
| |
| | |
| TLP kann nichts dagegen tun, stattdessen gibt es folgende Lösungsmöglichkeiten:
| |
| * Im BIOS eine der beiden Grafikeinheiten deaktivieren
| |
| * Verwendung von [http://wiki.ubuntuusers.de/Hybrid-Grafikkarten/Bumblebee Bumblebee]
| |
| * Verwendung von [http://wiki.ubuntuusers.de/Hybrid-Grafikkarten/PRIME Optimus/PRIME]
| |
| | |
| === Bildschirm flackert ===
| |
| Betroffene Hardware: ein Nutzer eines Dell Latitude 5480 [https://github.com/linrunner/TLP/issues/295 berichtete] "Bildschirm flackert mit einer uneinheitlichen Rate, wenn auch nicht so sporadisch."
| |
| | |
| Lösung: ASPM im Akku-Modus deaktivieren
| |
| PCIE_ASPM_ON_BAT=default
| |
| | |
| === Ich verwende PRIME um die dGPU abzuschalten, warum wird sie dennoch beim Booten aktiviert? ===
| |
| Lösung: die dGPU vom Runtime PM ausschließen.
| |
| | |
| TLP 1.0 und höher: Blacklisten des Treibers
| |
| RUNTIME_PM_DRIVER_BLACKLIST="nouveau nvidia"
| |
| TLP 0.9 und niedriger: Blacklisten des Geräts
| |
| RUNTIME_PM_BLACKLIST="01:00.0"
| |
| <u>Hinweis:</u> um zu überprüfen, ob "01:00.0" zur verbauten Nvidia dGPU passt, verwendet man den Befehl
| |
| lspci | grep VGA
| |
| Siehe auch [[TLP_Einstellungen#Runtime_Power_Management|Runtime PM]].
| |
| | |
| === Signifikant schlechtere Energieeinsparung nach dem Upgrade auf TLP 1.0 ===
| |
| TLP 1.0 und höher nimmt per Blacklist alle dGPUs vom Runtime Power Management aus. Für bestimmte Hardware/Kernel-Kombinationen bedeutet dies, dass die dGPU beim Systemstart nicht mehr automatisch deaktiviert wird.
| |
| | |
| Lösung: Entfernen aller dGPUs aus der Treiber-Blacklist
| |
| RUNTIME_PM_DRIVER_BLACKLIST="mei_me pcieport"
| |
| | |
| oder Einsatz eines Tools wie Bumblebee oder PRIME, um die dGPU beim Booten explizit zu deaktivieren.
| |
| | |
| === Bumblebee scheitert beim Wiedereinschalten der dGPU ===
| |
| Lösung: die dGPU vom Runtime PM ausschließen, siehe vorausgehenden Abschnitt.
| |
| | |
| = Laufwerke =
| |
| == Warum parkt meine Festplatte die Leseköpfe im Akkubetrieb so häufig (Klickgeräusche)? ==
| |
| Die TLP-Einstellung
| |
| DISK_APM_LEVEL_ON_BAT=128
| |
| entspricht der Ubuntu-Default-Einstellung und sollte nicht zu exzessiven Parkvorgängen (Stichwort "Load Cycle Count") führen. Leider interpretieren einige Hersteller, insbesondere bei neueren Plattenmodellen, die [[TLP_Einstellungen#Advanced_Power_Management_.28APM.29|APM-Eckwerte]] sehr "grosszügig", um den Stromverbrauch zu senken.
| |
| | |
| In einem solchen Fall kann es helfen, im Akkubetrieb einen geeigneten Wert > 128 durch Ausprobieren zu ermitteln (siehe [https://wiki.ubuntuusers.de/Notebook-Festplatten-Bug Notebook-Festplatten-Bug]).
| |
| | |
| == Warum funktioniert das automatische Anhalten der Festplatte (Spindown) nicht? ==
| |
| Die Verwendung von DISK_APM_LEVEL < 128 oder von DISK_SPINDOWN_TIMEOUT ermöglicht zwar das automatische Anhalten des Spindelmotors. In der Praxis greifen System und Anwendungen aber zu häufig auf die Festplatte zu und wecken sie wieder auf. Für dieses Problem existiert keine nachhaltige Lösung, da insbesondere zahlreiche Anwendungen angepasst werden müssten.
| |
| | |
| == Wie kann ich meine 2. Festplatte anhalten? ==
| |
| Abschalten nach 1 Minute (= '''12''' · 5 Sekunden) Inaktivität mit:
| |
| DISK_SPINDOWN_TIMEOUT_ON_AC="0 12"
| |
| DISK_SPINDOWN_TIMEOUT_ON_BAT="0 12"
| |
| Siehe auch [[TLP_Einstellungen#Spindelmotor_abschalten|Spindelmotor abschalten]].
| |
| | |
| == Warum läuft beim Wechsel Akku <> Netzbetrieb stets die Festplatte an? ==
| |
| TLP schreibt die Einstellungen für den APM-Level und den Timeout für das Abschalten des Spindelmotors bei jedem Wechsel der Stromquelle und beim Suspend/Resume. Durch den Schreibvorgang starten Festplatten immer den Spindelmotor. Um dies zu vermeiden, kann man entweder die betreffenden Einstellungen durch Auskommentieren ('#' am Zeilenanfang) deaktivieren oder das spezielle Schlüsselwort "keep" für die betroffene Festplatte einsetzen.
| |
| | |
| Siehe auch [[TLP_Einstellungen#Advanced_Power_Management_.28APM.29|APM]].
| |
| | |
| == Warum ist meine Crucial M4 SSD im Akkubetrieb so langsam? ==
| |
| Die Crucial M4 verringert in Abhängigkeit vom APM Level die Performance. Möchte man dies nicht, so kann man APM wie folgt ausschalten:
| |
| DISK_APM_LEVEL_ON_AC="255 255"
| |
| DISK_APM_LEVEL_ON_BAT="255 255"
| |
| | |
| == MediaBay / UltraBay: wieso wird trotz Konfiguration das optische Laufwerk im Akkubetrieb nicht ausgeschaltet? ==
| |
| Mögliche Ursachen:
| |
| | |
| '''ThinkPad ohne Ultrabay'''
| |
| | |
| Dazu zählen die Edge- und SL-Baureihen.
| |
| | |
| '''Inkompatibles Notebook'''
| |
| | |
| Die Funktion ist bisher nur mit ThinkPads getestet. Berichte und Fragen zu anderen Notebooks sind im [http://www.thinkpad-forum.de/thinkpad-software/linux-und-osx/84030-projektvorstellung-tlp---stromspareinstellungen-für-ubuntu/ Support-Thread] stets willkommen.
| |
| | |
| = Powertop =
| |
| == Erreicht man mit Powertop höhere Einsparungen als mit TLP? ==
| |
| Nein. TLPs Standardkonfiguration basiert auf denselben Regeln wie Powertops Empfehlungen. Ausnahmen hiervon sind in den folgenden Abschnitten aufgeführt.
| |
| | |
| == Steht Powertop im Konflikt zu TLP? ==
| |
| Im interaktiven Modus hat Powertop keinen Einfluss auf die Funktion von TLP.
| |
|
| |
| Erklärung: Powertop ist kein Power Management Tool, sondern lediglich ein Analysewerkzeug. Powertop kann man verwenden um die Leistungsaufnahme vor oder nach der Installation von TLP anzuzeigen, aber TLP nimmt seine Einstellungen unabhängig davon vor, ob Powertop installiert ist oder nicht. Nur wenn man powertop --auto-tune in den Systemstart aufnimmt, kommt es zu einem Konflikt mit TLP.
| |
| | |
| == Warum empfiehlt mir Powertop im Akkubetrieb trotz aktivem TLP weitere Stromspar-Einstellungen? ==
| |
| <u>Wichtig:</u> TLP wendet maximale Stromspar-Einstellungen nur im Akkubetrieb an, daher bitte vor dem Starten von Powertop das Netzteil abziehen!
| |
| | |
| Nicht alle Empfehlungen von Powertop in der Rubrik "Tunables" sind sinnvoll bzw. sicher zu verwenden.
| |
| | |
| === "VM writeback timeout" ===
| |
| Powertop erwartet auf einem Wert von 1500 hundertstel Sekunden (centisecs), wohingegen TLP Defaultwerte von 1500 am Netzteil und 6000 im Akkubetrieb setzt. Falls man Powertops Empfehlung folgen möchte, setzt man folgende [[TLP_Einstellungen#Dateisystem|Einstellung]]:
| |
| MAX_LOST_WORK_SECS_ON_BAT=15
| |
| | |
| === "SATA ALPM link power" ===
| |
| Bei einigen Notebook-Modellen läßt sich ALPM für bestimmte Links nicht von ''"max_performance"'' auf ''"min_power"'' umschalten. Dies ist der Fall z.B. für eine offene Verbindung zum Laufwerk in der (nicht angeschlossenen) Docking Station.
| |
| | |
| Stromsparende Umgehungslösung für ThinkPads der X-Serie: im BIOS unter ''"Security -> IO Port Access"'' den Zugriff auf das Laufwerk in der Ultrabase auf ''"disabled"'' stellen (Ersparnis ca. 0,4 W).
| |
| | |
| === "Wifi powersave" ===
| |
| * Einige WLAN-Karten, z.B. Intel 3945abg, unterstützen mit aktuellen Linux-Kerneln kein Powersave.
| |
| | |
| === "USB autosuspend" ===
| |
| TLP spart absichtlich USB-Eingabegeräte (HID), WWAN-Geräte (3G/UMTS, 4G/LTE, 5G) sowie [seit TLP 1.2] Scanner (verwaltet von libsane) vom Autosuspend aus, um den Benutzern Probleme mit "einschlafenden" Mäusen o.ä. zu ersparen.
| |
| | |
| Eingabegeräte kann man in die Whitelist aufnehmen (USB_WHITELIST, siehe [[TLP_Einstellungen#USB|USB]]) um Autosuspend zu aktivieren; für WWAN nutzt man:
| |
| USB_BLACKLIST_WWAN=0
| |
| | |
| == Powertop zeigt mir eine sehr hohe Leistungsaufnahme für Gerät XY an – was kann ich tun? ==
| |
| Es ist unmöglich die Leistungsaufnahme einzelner Notebook-Komponenten direkt zu messen, nur die Gesamtleistungsaufnahme ist am Akku messbar. In der Rubrik "Device stats" werden daher in der Spalte "Power est." grob geschätzte Werte angezeigt, die ignoriert werden sollten.
| |
| | |
| = Prozessortaktsteuerung =
| |
| == Wieso werden die Takt-Einstellungen nicht bzw. unvollständig umgesetzt? ==
| |
| Falls tlp-stat -p andere als die gewählten Einstellungen anzeigt, gibt es mehrere mögliche Ursachen:
| |
| | |
| === Ungültige Frequenzeinstellungen ===
| |
| <u>Lösung:</u> die gültigen Werte für den eigenen Prozessor werden von tlp-stat -p angezeigt. Beispiel:
| |
| /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies = 2400000 1600000 800000 [kHz]
| |
| | |
| === Kein ondemand Governor mit intel_pstate ===
| |
| | |
| /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver = intel_pstate
| |
| /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = powersave
| |
| | |
| Seit Kernel 3.9 wird auf Intel Sandy Bridge (oder neuerer) Hardware automatisch der neue Treiber intel_pstate verwendet. intel_pstate unterstützt als Governor nur noch powersave (empfohlener Standard) und performance, ondemand ist entfallen.
| |
| | |
| == tlp-stat -p zeigt "x86_energy_perf_policy: program [for your kernel] not installed." ==
| |
| Die Lösung hängt von der Distribution ab:
| |
| * Ubuntu: das Meta-Paket '''linux-tools-generic''' (bzw. '''linux-tools-generic-lts-*''' für HWE-Kernel) installieren; für Mainline-Kernel gibt es kein passendes Paket.
| |
| * Debian: das Paket '''linux-cpupower''' installieren
| |
| * Arch: das Paket '''x86_energy_perf_policy''' installieren.
| |
| * Fedora: das Paket '''kernel-tools''' installieren.
| |
| | |
| = Systembetrieb =
| |
| | |
| == Wie kann ich das TLP beenden oder vollständig deaktivieren? ==
| |
| '''Richtiger Weg:'''
| |
| * Konfiguration ändern: TLP_ENABLE=0
| |
| *Optional: Neustart zur Wiederherstellung der Kernel-Standardeinstellungen
| |
| | |
| <u>Hinweis:</u> die Deinstallation der Pakete deaktiviert TLP ebenfalls vollständig.
| |
| | |
| '''Falsche Wege:'''
| |
| * systemctl stop tlp.service - dies wird TLP nicht daran hindern, Energiespareinstellungen anzuwenden, wenn die Stromquelle (Netzteil/Akku) wechselt; je nach Konfiguration kann es auch dazu führen, dass WLAN und/oder Bluetooth/WWAN sofort abgeschaltet wird, was unerwünscht sein könnte.
| |
| * systemctl disable/mask tlp.service - dies verhindert nur, dass TLP beim Systemstart und Herunterfahren Ladeschwellen anwendet und Funkgeräte schaltet; die Energiespareinstellungen werden trotzdem angewendet (siehe oben).
| |
| | |
| == Wie starte ich TLP - und aktiviere geänderte Einstellungen? ==
| |
| '''Richtiger Weg''':
| |
| tlp start
| |
| <u>Hinweis:</u> Nach der Installation wird TLP beim Booten automatisch gestartet. Um einen Neustart des Systems zu vermeiden, können man es beim ersten Mal wie oben beschrieben manuell starten.
| |
| | |
| Voraussetzungen:
| |
| * TLP_ENABLE=1 ist konfiguriert
| |
| * Die systemd Service Units tlp.service und tlp-sleep.service (nur TLP 1.2.2 oder älter) sind aktiviert (die Pakete einiger Distributionen tun dies nicht standardmäßig); die Ausgabe von tlp-stat -s weist darauf hin, wenn dies nicht der Fall ist.
| |
| | |
| '''Falscher Weg:'''
| |
| * systemctl start/neustart tlp.service - abhängig von der Konfiguration kann dies WLAN und/oder Bluetooth/WWAN und den Laufwerksschacht sofort ausschalten, was unerwünscht sein könnte; tlp start wendet hingegen nur Stromspareinstellungen an.
| |
| | |
| == systemd: muss ich die TLP Service Units aktivieren? ==
| |
| Ja. Die Service Units sind unabdingbar für den Betrieb von TLP:
| |
| | |
| * '''tlp.service:''' wendet Stromspareinstellungen an und schaltet Funkgeräte bei Systemstart und Herunterfahren
| |
| * '''tlp-sleep.service:''' wendet Stromspareinstellungen an bei Suspend und Resume (nur für TLP 1.2.2 und älter)
| |
| | |
| == Netzteil wird beim Anstecken nicht erkannt ==
| |
| Betroffene Hardware: Dell XPS 15 9550/9560 (nur beim Start ohne Netzteil)
| |
| | |
| Symptome: tlp-stat -s zeigt an
| |
| Power source = battery
| |
| | |
| tlp-stat --psus zeigt nur den Akku an
| |
| /sys/class/power_supply/BAT0/type:Battery
| |
| /sys/class/power_supply/BAT0/present:1
| |
| /sys/class/power_supply/BAT0/device/path:_SB_.BAT0
| |
| | |
| Ursache: BIOS-Fehler, die DSDT muss korrigiert werden (siehe letzter Kommentar in Kernel-Fehler [https://bugzilla.kernel.org/show_bug.cgi?id=156171 #156171]).
| |
| | |
| Referenzen: Issues [https://github.com/linrunner/TLP/issues/223 #223], [https://github.com/linrunner/TLP/issues/343 #343], [https://github.com/linrunner/TLP/issues/362 #362].
| |
| | |
| Lösungen:
| |
| * Update auf TLP 1.2 - empfohlen
| |
| * Neustart mit angeschlossenem Netzteil
| |
| * BIOS-Update durch den Hersteller
| |
| * DSDT selbst korrigieren
| |
| | |
| == Herunterfahren hängt vor dem Abschalten ==
| |
| Lösung: das Kernelmodul mei_me zur RUNTIME_PM_DRIVER_BLACKLIST hinzufügen.
| |
| | |
| == Herunterfahren startet den Laptop neu statt ihn abzuschalten ==
| |
| Benutzer von HP Laptops berichten von diesem Problem. Abhilfe schafft des Deaktivieren von Wake-on-LAN im BIOS.
| |
| | |
| == Spontanes Herunterfahren im Akkubetrieb ==
| |
| Symptom: der Laptop schaltet sich beim Wechsel in den Akkubetrieb spontan ab.
| |
| | |
| Betroffene Hardware: Acer Aspire V5-591G mit Kernel 4.4.
| |
| | |
| == Ethernet nach Resume ohne Funktion ==
| |
| Ein Benutzer eines Dell XPS mit Kernel 4.4 berichtete dieses Problem.
| |
| | |
| Lösung: Wake-on-LAN aktivieren
| |
| WOL_DISABLE=N
| |
| | |
| == Exit Code 4 ==
| |
| Symptom: im Journal taucht die Meldung
| |
| ERROR: systemd-udevd[1234]: Process '/usr/bin/tlp auto' failed with exit code 4
| |
| auf.
| |
| | |
| Lösung: Update auf TLP 1.2
| |
| | |
| = Akkufunktionen =
| |
| == Was versteht man unter "Akkufunktionen"? ==
| |
| Akkufunktionen meint Ladeschwellen sowie den/die Akku/s im Betrieb am Netzteil entladen bzw. rekalibrieren zu können.
| |
| | |
| <u>Abgrenzung:</u>
| |
| * Akkufunktionen sind derzeit ausschließlich für IBM/Lenovo ThinkPads verfügbar!
| |
| * Alle anderen Lenovo Laptop-Modelle einschließlich IdeaPads – sowie natürlich andere Laptop-Fabrikate – werden nicht unterstützt. Hierfür bitte keine Fehlerberichte einreichen.
| |
| * Mit Akkufunktionen sind ''nicht'' zusätzliche Stromsparfunktionen für ThinkPads gemeint.
| |
| | |
| == Was sind gute Akku-Ladeschwellen? ==
| |
| <u>Hinweis:</u> neuere ThinkPad-Modelle benötigen aufgrund ihrer "Dual Mode Battery Firmware" möglicherweise keine Ladeschwellen ; siehe [https://forums.lenovo.com/t5/Windows-10/Power-Manager-for-Windows-10/m-p/2129075#M794 Lenovo Forum] und [https://support.lenovo.com/de/de/solutions/ht104070 Lenovo Support].
| |
| | |
| Die Werkseinstellungen für die Akku-Ladeschwellen eines ThinkPads sind wie folgt: beim Anschliessen des Netzteils beginnt der Akku ab 96% zu laden und stoppt bei 100%. Diese Einstellungen sind optimiert für maximale Laufzeit. Ein dauerhaft hoher Ladezustand führt jedoch über die Jahre zu einem Rückgang der Ladekapazität des Akkus. Um dieses Problem abzumildern, können die Ladeschwellen justiert werden – verbunden mit mehr oder weniger starken Auswirkungen auf die Laufzeit.
| |
| | |
| Alles hängt davon ab, wie das ThinkPad genutzt wird, oder genauer, welche minimale Laufzeit unterwegs für seinen Benutzer akzeptabel ist. Am Ende geht es also um eine Abwägung höhere Akkulaufzeit vs. Verringerung der Akkulebensdauer.
| |
| | |
| Wenn das ThinkPad die meiste Zeit am Netzteil betrieben und selten abgesteckt wird, dann kann eine Maximierung der Lebensdauer auf Kosten der Laufzeit akzeptabel sein, d.h. 40% für die untere und 50% für die obere Ladeschwelle.
| |
| | |
| Wird es hingegen zumeist ohne Netzteil verwendet, dann erlaubt eine untere Schwelle von 85% und eine Obere von 90% eine wesentlich höhere Laufzeit und gleichzeitig einen Vorteil bei der Lebensdauer gegenüber den Werkseinstellungen.
| |
| | |
| Die Standardeinstellungen von TLP (75%/80%, sofern die betreffenden Konfigurationszeilen vom Benutzer einkommentiert wurden – sind noch ein wenig schonender im Hinblick auf die Lebensdauer.
| |
| | |
| Beim oben Gesagten ist stets zu bedenken, dass die untere Ladeschwelle die kritischere Einschränkung für die Laufzeit darstellt, da sie den niedrigsten vorkommenden Ladezustand definiert, der bei angeschlossenem Netzteil vorkommen kann.
| |
| | |
| Ausserdem soll daran erinnert werden, dass TLP über ein Kommando zum Voll-Laden verfügt (tlp fullcharge), falls man vorübergehend die Laufzeit maximieren möchte (z.B. auf Reisen).
| |
| | |
| == Welches Kernelmodul brauche ich für meine Hardware, tp-smapi oder acpi-call? ==
| |
| | |
| <u>Voraussetzung:</u> nur die neueste Version von TLP stellt präzise Empfehlungen sicher.
| |
| | |
| Man prüft das Ende der Ausgabe von tlp-stat -b, Abschnitt "Recommendations", ob folgende Zeilen auftauchen
| |
| Install tp-smapi kernel modules for ThinkPad battery thresholds and recalibration
| |
| Install acpi_call kernel module for ThinkPad battery thresholds and recalibration
| |
| Install acpi_call kernel module for ThinkPad battery recalibration
| |
| und installiert das betreffende Paket, wie in der
| |
| [[TLP_-_Linux_Stromsparen#Installieren|Installationsanleitung]]
| |
| für die eingesetzte Distribution beschrieben.
| |
| | |
| Die allermeisten ThinkPad-Modelle benötigen nur eines der obigen Kernelmodule. Das kann man feststellen, indem man die Ausgabe von tlp-stat -b auf folgende Zeilen prüft
| |
| tpacpi-bat = inactive (unsupported hardware)
| |
| tp-smapi = inactive (unsupported hardware)
| |
| und das nicht benötigte Paket entfernt (tpacpi-bat meint acpi-call). Es ist jedoch kein Problem, beide installiert zu lassen.
| |
| | |
| === natacpi - Die ultimative Lösung am Horizont ===
| |
| Ab Kernel 4.17 wird tpacpi-bat durch eine neue, native Kernel-API namens 'natacpi' ersetzt (die Bestandteil des Kernelmoduls thinkpad_acpi ist). tlp-stat -b zeigt dies wie folgt an:
| |
| +++ Battery Features
| |
| natacpi = active (data, thresholds)
| |
| tpacpi-bat = active (recalibrate)
| |
| tp-smapi = inactive (ThinkPad not supported)
| |
| | |
| Weitere Patches für das Entladen (force_discharge) wurden bis Kernel 5.5 noch nicht integriert. Die vollständige Umsetzung wird wie folgt aussehen:
| |
| +++ Battery Features
| |
| natacpi = active (data, thresholds, recalibrate)
| |
| tpacpi-bat = inactive (superseded by natacpi)
| |
| tp-smapi = inactive (ThinkPad not supported)
| |
| Mit der vollen natacpi-Unterstützung benötigt man keine externen Kernelmodul-Pakete mehr.
| |
| | |
| Ausführlichere Infos zu natacpi finden sich im Thread zu [https://thinkpad-forum.de/threads/218292-beendet-TLP-1-2-Beta-Test TLP 1.2 Beta].
| |
| | |
| == Warum wird mein Akku trotz eingestellter Ladeschwellen auf 100% geladen? ==
| |
| Hier gibt es eine ganze Reihe möglicher Ursachen:
| |
| === Notebook ist kein ThinkPad ===
| |
| Akkuladeschwellen und -rekalibrierung funktionieren nur mit ThinkPads.
| |
| | |
| <u>Wichtig:</u> andere Lenovo-Modelle, einschließlich IdeaPads, sowie andere Fabrikate, werden nicht unterstützt.
| |
| | |
| === Kernelmodul ist nicht installiert ===
| |
| Symptom: tlp-stat -b zeigt die Meldung
| |
| tpacpi-bat = inactive (kernel module 'acpi_call' not installed)
| |
| oder
| |
| tp-smapi = inactive (kernel module 'tp_smapi' not installed)
| |
| | |
| Lösung: siehe [[TLP_FAQ#Welches_Kernelmodul_brauche_ich_f.C3.BCr_meine_Hardware.2C_tp-smapi_oder_acpi-call.3F|Welches Kernelmodul]].
| |
| | |
| === Fedora Release Upgrade ===
| |
| Es kann erforderlich sein, die Kernelmodule neu zu bauen (als root):
| |
| akmods --force
| |
| | |
| === Paket acpi-call-dkms läßt sich nicht installieren ===
| |
| Debian-Derivate mit Kernel >= 4.12 benötigen mindestens die Paketversion 1.1.0-4.
| |
| | |
| === Kernelmodul acpi-call lädt nicht ===
| |
| Symptom: tlp-stat -b zeigt die Meldung
| |
| tpacpi-bat = inactive (kernel module 'acpi_call' load error)
| |
| Lösung: das Kernelmodul manuell laden mit
| |
| sudo modprobe -v acpi_call
| |
| und ggf. mit der Fehlermeldung im Forum nachfragen.
| |
| | |
| <u>Hinweis:</u> Secure Boot muss deaktiviert sein, ansonsten lädt acpi-call nicht.
| |
| | |
| === Paket tp-smapi-dkms läßt sich nicht installieren ===
| |
| Symptom (Ubuntu): die Installation des Pakets zeigt die Fehlermeldung
| |
| Setting up tp-smapi-dkms (0.41-1) ...
| |
| Creating symlink /var/lib/dkms/tp-smapi/0.41/source ->
| |
| /usr/src/tp-smapi-0.41
| |
| DKMS: add completed.
| |
| Error! Your kernel headers for kernel 3.X.0-YY-generic cannot be found.
| |
| Please install the linux-headers-3.X.0-YY-generic package,
| |
| or use the --kernelsourcedir option to tell DKMS where it's located
| |
| | |
| Lösung: das Paket '''linux-generic-headers''' nachinstallieren.
| |
| | |
| Symptom (Ubuntu 16.04.2, HWE Kernel 4.8): die Installation des Pakets zeigt die Fehlermeldung
| |
| Setting up tp-smapi-dkms (0.41-1) ...
| |
| make KERNELRELEASE=4.8.0-46-generic -C /lib/modules/4.8.0-46-generic/build M=/var/lib/dkms/tp-smapi/0.41/build....(bad exit status: 2)
| |
| Error! Bad return status for module build on kernel: 4.8.0-46-generic (x86_64)
| |
| Lösung: entweder das [[TLP_-_Linux_Stromsparen#Ubuntu|TLP-PPA aktivieren]] und ein Paketupdate durchführen (empfohlen) oder Paketversion 0.43-1 aus Focal [https://packages.ubuntu.com/focal/tp-smapi-dkms herunterladen] und manuell installieren.
| |
| | |
| === Kernelmodul tp-smapi lädt nicht ===
| |
| Symptom: tlp-stat -b zeigt die Meldung
| |
| tp-smapi = inactive (kernel module 'tp_smapi' load error)
| |
| | |
| Lösung: zunächst versucht man, das Kernelmodul manuell zu laden mit
| |
| sudo modprobe -v tp_smapi
| |
| und anhand der Fehlermeldung mit den dazu in [http://wiki.ubuntuusers.de/TP-SMAPI#Kernelmodul-manuell-laden tp-smapi] beschriebenen Maßnahmen fortfahren bzw. eine Anfrage im Forum starten.
| |
| | |
| <u>Hinweise:</u>
| |
| * Secure Boot muss deaktiviert sein, ansonsten lädt tp-smapi nicht.
| |
| * Libreboot unterstützt tp-smapi nicht.
| |
| * tp-smapi unterstützt neuere Modelle nicht, siehe [[TLP_FAQ#Welches_Kernelmodul_brauche_ich_f.C3.BCr_meine_Hardware.2C_tp-smapi_oder_acpi-call.3F|Welches Kernelmodul]].
| |
| | |
| === ThinkPad T420(s)/T520/W520/X220 ===
| |
| Bei der Sandy-Bridge-Generation unterstützt tp-smapi weder die untere Ladeschwelle noch das Rekalibrieren.
| |
| | |
| Die Ausgabe von tlp-stat zeigt
| |
| /sys/devices/platform/smapi/BAT0/start_charge_thresh = (not available)
| |
| Die Ausgabe von tlp setcharge bzw. fullcharge zeigt
| |
| start => Warning: cannot set threshold.
| |
| tlp discharge bzw. recalibrate schlagen fehl
| |
| Error: discharge function not available for this laptop.
| |
| | |
| '''Lösungen:'''
| |
| * Kernel >= 4.19 mit natacpi installieren
| |
| * TLP verwendet statt tp-smapi automatisch die Alternative tpacpi-bat sofern das benötigte Kernelmodul acpi-call installiert ist – siehe [[TLP_FAQ#Welches_Kernelmodul_brauche_ich_f.C3.BCr_meine_Hardware.2C_tp-smapi_oder_acpi-call.3F|Welches Kernelmodul]]
| |
| | |
| === ThinkPad T430(s)/T530/W530/X230 und alle neueren Modelle ===
| |
| '''Lösungen:'''
| |
| * Kernel >= 4.19 mit natacpi installieren
| |
| * TLP verwendet statt tp-smapi automatisch die Alternative tpacpi-bat sofern das benötigte Kernelmodul acpi-call installiert ist – siehe [[TLP_FAQ#Welches_Kernelmodul_brauche_ich_f.C3.BCr_meine_Hardware.2C_tp-smapi_oder_acpi-call.3F|Welches Kernelmodul]]
| |
| | |
| === ThinkPad E495 ===
| |
| Symptom: Ladeschwellen wurden zwar in den Embedded Controller (EC) geschrieben, tlp-stat -b liest sie auch wie konfiguriert zurück:
| |
| /sys/class/power_supply/BAT0/charge_start_threshold = 45 [%]
| |
| /sys/classes/power_supply/BAT0/charge_stop_threshold = 60 [%]
| |
| Dennoch wirken Sie nicht.
| |
| | |
| Ursache: Fehler in der Embedded Controller (EC) Firmware von Lenovo.
| |
| | |
| Lösung: die Ladeschwellen vollständig entfernen mit
| |
| sudo tlp fullcharge
| |
| dann wie unten beschrieben fortfahren.
| |
| | |
| === ThinkPad L420/520, SL300/400/500, X121e ===
| |
| Diese Modelle werden weder durch tp-smapi noch durch tpacpi-bat oder natacpi unterstützt. Bitte keine Fehlerberichte dazu erstellen.
| |
| | |
| === Akku wurde gewechselt ===
| |
| Durch Herausnehmen des Akkus können bei manchen Modellen die aktiven Ladeschwellen verloren gehen. Nach dem (Wieder-)Einsetzen eines Akkus wirken zunächst die Werkseinstellungen (96/100%). Die in [[TLP_Einstellungen#ThinkPad_Akku|TLP konfigurierten Ladeschwellen]] werden erst aktiv, nachdem das
| |
| * System neu gestartet
| |
| * wieder heruntergefahren und ausgeschaltet
| |
| wurde. Alternativ kann man sie mit
| |
| sudo tlp setcharge
| |
| sofort setzen, siehe [[TLP_-_Linux_Stromsparen#Ladeschwellen_auf_tempor.C3.A4re_Werte_setzen|temporäre Schwellen setzen]].
| |
| | |
| == Die von tlp-stat -b angezeigten Ladeschwellen entsprechen nicht den Einstellungen ==
| |
| Mögliche Ursachen:
| |
| | |
| === Konfiguration wurde nicht aktiviert ===
| |
| Nach Anpassungen der Einstellungsdatei ist ein Neustart oder der Aufruf von
| |
| sudo tlp start
| |
| bzw.
| |
| sudo tlp setcharge
| |
| erforderlich.
| |
| | |
| === ThinkPad Edge, E/L/S-Reihe, SL410/510, Yoga-Reihe ===
| |
| Bei diesen Baureihen entsprechen die mit tlp-stat -b ausgelesenen Werte für die Akkuladeschwellen nicht den zuvor geschriebenen Werten. So liefert z.B. das Setzen von START_CHARGE_THRESH_BATx=75 / STOP_CHARGE_THRESH_BATx=80 beim Auslesen stattdessen 75 / 74. Das Verhalten wird durch die Firmware (UEFI/BIOS) der betroffenen Modelle verursacht, nicht durch TLP. Nichtsdestotrotz funktionieren die Ladeschwellen wie eingestellt!
| |
| | |
| == Untere Ladeschwelle wirkt nach Änderung nicht ==
| |
| | |
| Betroffene Modelle: X240, Yoga 12 (Berichte von Nutzern)
| |
| | |
| Lösung: um die ''neue'' untere Ladeschwelle zu aktivieren, kann es nötig sein, ''nach'' dem Setzen der neuen Ladeschwelle – via tlp setcharge oder Reboot – den Akku einmalig unter den Wert der ''alten'' Ladeschwelle zu entladen.
| |
| | |
| == tlp fullcharge BAT1 stoppt bei ~80% ==
| |
| | |
| Betroffene Hardware: ThinkPads T440 (basierend auf Benutzer-Feedback).
| |
| | |
| Symptom: obwohl die Stop-Schwelle entweder durch die Konfiguration oder durch tlp fullcharge/setcharge auf 100% gesetzt wurde, endet der Ladevorgang für BAT1 bei etwa 80%.
| |
| | |
| Ursache: dies ist in der Embedded Controller (EC) Firmware von Lenovo fest einprogrammiert. Nachdem BAT1 den Schwellenwert von 80% erreicht hat, beginnt der Ladevorgang mit BAT0 bis 100%, danach fährt BAT1 bis 100% fort. Falls nun für BAT0 eine Stop-Schwelle festgelegt wurde, kann es sein, dass der letzet Schritt nie stattfindet.
| |
| | |
| Keine Lösung: die Lenovo-Firmware bietet keine Möglichkeit, das Verhalten zu ändern.
| |
| | |
| == Unstetigkeiten des Ladestands bei ThinkPad T420(s)/T520/W520/X220 (und allen neueren Modellen) ==
| |
| Symptom: einige Benutzer berichten von stark reduzierter Akkukapazität oder plötzlichem Abfall des Ladestands von ca. 30% auf Null.
| |
| | |
| Wahrscheinliche Ursache: Konflikt mit der [https://support.lenovo.com/de/de/solutions/ht104070 Dual Mode Battery Firmware].
| |
| | |
| Lösung: die Ladeschwellen komplett entfernen oder nur die untere Ladeschwelle verwenden; anschließend den Akku einmal rekalibrieren.
| |
| | |
| <u>Hinweis:</u> dies ist ein Software-Phänomen, der Akku wird dadurch nicht beeinträchtigt.
| |
| | |
| == Wieso wird trotz erreichter Ladeschwelle im Panel weiterhin angezeigt, dass der Akku geladen wird? ==
| |
| Existierende Panel-Applets fragen entweder upowerd ab oder sie verwenden die Standard-Schnittstelle des Kernels, die beim Eingriff von Ladeschwellen den Ladestatus nicht richtig wiedergibt. Konkret zeigt tlp-stat -b in diesem Fall für '''/sys/class/power_supply/BATx/status''' den Wert "Unknown". Dieses Verhalten läßt sich nicht ändern.
| |
| | |
| Bei ThinkPad-Modellen die tp-smapi unterstützen, zeigt tlp-stat -b hingegen unter '''/sys/devices/platform/smapi/BATx/''' stets den tatsächlichen Zustand.
| |
| | |
| == Funktionieren die Ladeschwellen auch wenn TLP/Linux nicht läuft? ==
| |
| Ja. Der Ladevorgang wird nicht durch Software gesteuert, die auf dem Betriebssystem läuft, sondern durch die Firmware des Embedded Controllers (EC). TLP schreibt lediglich die Ladeschwellen in die entsprechenden EC-Register (über tp-smapi, tpacpi-bat oder natacpi). Einmal in der Hardware gespeichert, bleiben die Ladeschwellen dauerhaft wirksam. Zum Entfernen siehe unten.
| |
| | |
| == Was genau tut die untere Ladeschwelle START_CHARGE_THRESH_BATx? ==
| |
| START_CHARGE_THRESH_BATx sorgt dafür, dass der Akku nach kurzen Entladevorgängen beim Anstecken des Netzteils nicht sofort wieder geladen wird. Der Ladevorgang startet erst, wenn beim vorausgegangenen Entladen der Wert von START_CHARGE_THRESH_BATx unterschritten wurde. Liegt hingegen beim Anstecken des Netzteils die Ladung über START_CHARGE_THRESH_BATx, dann wird nicht geladen.
| |
| | |
| == Warum beginnt der Akku nicht sich zu entladen, wenn die Stop-Schwelle während des Ladevorgangs erreicht wird? ==
| |
| | |
| Anmerkung des Autors: manchmal gelangen Benutzer zu dieser Fehleinschätzung, ohne dass ich verstanden hätte, wie es passiert. Dies ist der Versuch, sie wieder herauszuführen.
| |
| | |
| Die Aufgabe der Stop-Schwelle besteht darin, den Batterieverschleiß zu verringern, indem der Ladezustand auf unter 100% begrenzt wird. Der Ladevorgang stoppt also am Schwellwert und die Batterie wird nicht entladen, solange das Ladegerät angeschlossen bleibt.
| |
| | |
| Dies ist das vom Hersteller beabsichtigte Verhalten. Es ist in der EC-Firmware (siehe oben) fest einprogrammiert und verhält sich auch für das ab Werk installierte Betriebssystem identisch.
| |
| | |
| Im Gegensatz dazu würde eine wiederholte Entladung der Batterie während des Betriebs am Netzteil, wenn sie den gewünschten maximalen Ladezustand erreicht hat, zu einem absurd hohen Verschleiß (d.h. Ladezyklen) führen, ohne dass daraus ein Nutzen gezogen würde.
| |
| | |
| == Kann man durch Setzen der unteren Ladeschwelle das weitere Entladen des Akkus verhindern? ==
| |
| Nein. Entladen des Akkus läßt sich nur durch Anstecken des Netzteils oder Ausschalten des ThinkPads verhindern.
| |
| | |
| == Wie kann ich die Ladeschwellen entfernen? ==
| |
| Man entfernt die Ladeschwellen aus der Konfiguration durch Auskommentieren mit '#'
| |
| #START_CHARGE_THRESH_BAT0=75
| |
| #STOP_CHARGE_THRESH_BAT0=80
| |
| und aktiviert mit
| |
| sudo tlp fullcharge
| |
| unmittelbar die Werkseinstellung 96%/100%.
| |
| | |
| == Mein Akku läßt sich nach einer Rekalibration nicht mehr aufladen, die Anzeige zeigt permanent X% ==
| |
| Wahrscheinlichste Ursache: der Akku ist defekt (und war dies auch schon vor der Rekalibration).
| |
| | |
| == Warum zeigt tlp-stat -b "cycle_count = (not supported)" an? ==
| |
| Der "Cycle count" (= Anzahl der Ladezyklen) ist nicht für alle Laptops verfügbar. Ausnahme sind ThinkPads die tp-smapi unterstützen, sowie manche neuere Hardware.
| |
| | |
| = USB =
| |
| == USB-Gerät funktioniert nicht ==
| |
| Symptom: einige USB-Geräte arbeiten nicht zuverlässig, wenn TLP den USB Autosuspend Modus aktiviert.
| |
|
| |
| Lösung: mit lsusb die USB-Geräte-ID des betreffenden Geräts ermitteln, in [[TLP_Einstellungen#USB|USB_BLACKLIST]] eintragen (dabei das Kommentarzeichen '#' am Anfang der Zeile entfernen) und das Gerät erneut anstecken.
| |
| | |
| <u>Hinweis:</u> TLP nimmt alle Eingabegeräte (HID), also Tastaturen und Mäuse, sowie [seit TLP 1.2] Scanner (libsane) automatisch vom Autosuspend-Modus aus. Für sie ist kein Eintrag in USB_BLACKLIST erforderlich.
| |
| | |
| == Smartphone wird am USB-Anschluss nicht geladen ==
| |
| '''Lösungen'''
| |
| | |
| TLP 1.0 und höher: Autosuspend deaktivieren mit
| |
| USB_BLACKLIST_PHONE=1
| |
| und das Smartphone erneut anstecken.
| |
| | |
| TLP 0.9 und niedriger: mit lsusb die USB-Geräte-ID des Smartphones ermitteln, in [[TLP_Einstellungen#USB|USB_BLACKLIST]] eintragen und das Smartphone erneut anstecken.
| |
| | |
| = Warnungen =
| |
| == Welche Art Warnungen zeigt "tlp-stat -w" an? ==
| |
| Derzeit prüft der Befehl das Kernel Log auf Fehler die möglicherweise durch SATA ALPM verursacht werden.
| |
| | |
| == Was ist zu tun wenn Warnungen angezeigt werden? ==
| |
| TLPs frühere [bis TLP 1.1] Standard-Einstellung im Akkubetrieb
| |
| SATA_LINKPWR_ON_BAT=min_power
| |
| ist auf maximale Energieeinsparung ausgelegt. Hier wählt man probeweise einen weniger aggressiven Wert, d.h. für Kernel >= 4.15
| |
| SATA_LINKPWR_ON_BAT=med_power_with_dipm
| |
| bzw. für Kernel < 4.15
| |
| SATA_LINKPWR_ON_BAT=medium_power
| |
| oder
| |
| SATA_LINKPWR_ON_BAT=max_performance
| |
| oder man deaktiviert die Einstellung komplett – siehe [[TLP_Einstellungen#AHCI_Link_Power_Management_.28ALPM.29|ALPM]].
| |
| | |
| Nach dem Ändern der Einstellung ist vor einer erneuten Prüfung ein Neustart erforderlich.
| |
| | |
| Vorstehendes gilt sinngemäß für SATA_LINKPWR_ON_AC.
| |
| | |
| <u>Hinweis:</u> der Unterschied in der Leistungsaufnahme zwischen min_power und max_performance kann sich abhängig von der Hardware auf mehr als 1 W belaufen.
| |
| | |
| == Was tun wenn die Änderung der Einstellungen die Fehlermeldungen nicht beseitigt? ==
| |
| Falls nur 1 oder 2 Fehler direkt nach dem Systemstart oder dem Wechsel der Stromquelle auftreten, kann man diese (nach Berichten von Benutzern) einfach ignorieren.
| |
| | |
| Im Fall einer hohen Anzahl von Fehlern, versucht man es mit einen neueren Kernel.
| |
| | |
| == Was ist der Grund für die Fehlermeldungen? ==
| |
| Kandidaten sind:
| |
| * Fehlerhafte Implementierung von ALPM in der Firmware der Platte, dem SATA Controller oder dem System BIOS
| |
| * Probleme zwischen Controller und Platte
| |
| * Fehler im Kernel-Treiber
| |
| | |
| = Verschiedenes =
| |
| == Wofür steht "TLP"? ==
| |
| TLP ist keine Abkürzung, es ist nur ein dreibuchstabiger Name.
| |
| | |
| == Wie erreiche ich, daß Feature "xyzzy" in TLP aufgenommen wird? ==
| |
| Einfach im [https://thinkpad-forum.de/threads/82441-Projektvorstellung-TLP-%E2%80%93-Linux-Stromsparen Support-Thread] melden und den Wunsch nachvollziehbar beschreiben:
| |
| * Ziel des Features: was soll erreicht werden und warum?
| |
| * Welche Anwendungsfälle sind zu berücksichtigen bzw. machen das Feature notwendig?
| |
| * Vorhandene eigene Skripte (oder Links zu solchen) beifügen
| |
| <u>Hinweis:</u> der Autor behält sich vor, Featurewünsche zu einem von ihm gewählten Termin oder auch gar nicht zu implementieren.
| |
| | |
| Grundsätzlich werden in TLP nur Dinge implementiert, die mit der Senkung des Stromverbrauchs oder dem Akkubetrieb im Allgemeinen zu tun haben. Siehe dazu auch die untenstehende Abgrenzung.
| |
| | |
| == Abgrenzung - welche Themen berücksichtigt TLP (absichtlich) nicht? ==
| |
| * Helligkeit des LCD-Backlights: kollidiert mit vorhandener Funktionalität z.B. des Gnome Power Managers
| |
| * Lüftersteuerung: Lösungen sind bereits vorhanden, z.B. Thinkfan.
| |
| * Einbindung von benutzereigenen Skripten: Support-Gründe sprechen dagegen.
| |
| * Auswahl des aktiven Akkus bei ThinkPads mit mehreren Akkus ("battery balancing"): die Lenovo-Firmware bietet keine Möglichkeit, das Entladeverhalten zu steuern – weder manuell noch automatisch.
| |
| | |
| = Links =
| |
| == TLP ==
| |
| * [[TLP - Linux Stromsparen]] – Installation, Benutzerdokumentation
| |
| * [[TLP Einstellungen]] – Konfiguration
| |
| * [https://linrunner.de/en/tlp/docs/tlp-troubleshooting.html TLP Troubleshooting] – Anleitung zur Fehlersuche (englisch)
| |
| * [https://linrunner.de/en/tlp/docs/tlp-developer-documentation.html TLP Developer Documentation] – Hinweise zur Paketierung (englisch)
| |
| * [https://linrunner.de/tlp TLP] – Projekt-Homepage
| |
| * [https://linrunner.de/en/tlp/tlp.html TLP] – English Documentation
| |
| | |
| == Weiteres ==
| |
| * [[Thinkfan]] – einfaches Lüftersteuerungsprogramm
| |
| * [https://github.com/d4nj1/TLPUI TLPUI] – GUI zur Verwaltung der TLP-Einstellungen
| |
| | |
| [[Category:Linux]]
| |
| [[Category:Stromsparen]]
| |
| [[Category:Ubuntu]]
| |
Die Inhalte dieser Seite waren veraltet und wurden deshalb vom TLP Autor entfernt.
