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!

Thema KI: Anfragen à la "die KI hat gesagt, es hat aber nicht funktioniert. Was meinst Du dazu?" werden nicht supported. Ich werde "AI Slop" nicht kommentieren und will auch in diesem Thread keinerlei halluzinierte KI-Inhalte sehen, die dann später per Suchmaschine (oder wiederum KI) auffindbar sind!

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

 

[thickpad]

Ich habs jetzt durchgespielt. Der Sweetspot bei diesem X1 Carbon Gen9 ist auf circa 60% Max_Perf. Die gesetzten Taktraten von der IRIS XE reichen so um noch Videofenster im Bravebrowser flüssig über die MOnitore ziehen zu können. Dann bleibt man im Bereich des Basistaktes und hat ein lautloses Gerät. Das führt dazu das selbst mit einem 34 Zoll Monitor der Lüfter nicht anspricht mit Tab-Verhalten des Todes und circa 20 GB RAM Auslastung.

Auch muss ich mal wieder eine Lanze für CachyOS brechen, es ist alles in den Repositorys was man braucht und grad diese Limine basierte Installation ist ja dermaßen deppensicher. es macht ständig Snapshots, vor und nach jeder Paketinstallation, passt was nicht boot zurück. I like.

Nice find: Man kann dieses Gerät tatsächlich mit pcie_aspm=force booten und auf powersupersave gehen ohne das dummes Zeug passiert.


Das ist wirklich sehr sparsam!

Endgültige Config-Snippet:

~
❯ cat /etc/tlp.d/01-x1-carbon-silent.conf
# ============================================================================
# █▀▄▀█ ▄▀█ █▀▀ ▀█▀ █▀▀ █▀█   █▀▀ █▀█ █▄░█ █▀▀ █▀▀ █▀▀
# █░▀░█ █▀█ ▄▄█ ░█░ ██▄ █▀▄   █▄▄ █▄█ █░▀█ █▀░ █▄█ ██▄
# ============================================================================
# Projekt: Silent-X1-Stack (X1 Carbon Gen 9 / CachyOS)
# Hardware: Intel Tiger Lake-LP | Crucial T500 NVMe
# Status: GPU-Boost-Fix (Battery) & Triple-Profile Logic
# ============================================================================

# --- [ 1. SYSTEM-STEUERUNG ] ------------------------------------------------
# TLP_ENABLE: Aktiviert das Energiemanagement.
# TLP_AUTO_SWITCH: Ermöglicht das Umschalten via KDE-Regler (AC/BAT/SAV).
TLP_ENABLE=1
TLP_AUTO_SWITCH=1


# --- [ 2. CPU POWER-PROFILES (INTEL P-STATE) ] ------------------------------
# Mapping: AC = Leistung | BAT = Ausgeglichen | SAV = Energiesparen

# >>> PROFILE: PERFORMANCE (Netzbetrieb / Volle Power)
CPU_ENERGY_PERF_POLICY_ON_AC=performance
PLATFORM_PROFILE_ON_AC=performance
CPU_MAX_PERF_ON_AC=100
CPU_BOOST_ON_AC=1
#CPU_HWP_DYN_BOOST_ON_AC=1

# >>> PROFILE: BALANCED (Der 2.6 GHz Sweetspot / Silent-Ziel 40°C)
CPU_ENERGY_PERF_POLICY_ON_BAT=balance_power
PLATFORM_PROFILE_ON_BAT=balanced
CPU_MAX_PERF_ON_BAT=60
CPU_BOOST_ON_BAT=1
#CPU_HWP_DYN_BOOST_ON_BAT=0

# >>> PROFILE: POWER-SAVER (Ultra-Silent Mode @ ~1.1 GHz)
CPU_ENERGY_PERF_POLICY_ON_SAV=power
PLATFORM_PROFILE_ON_SAV=low-power
CPU_MAX_PERF_ON_SAV=40
CPU_BOOST_ON_SAV=1
#CPU_HWP_DYN_BOOST_ON_SAV=0


# --- [ 3. CONNECTIVITY & WIRELESS ] -----------------------------------------
# WLAN-Sparmodus zur Reduktion der Abwärme unter dem Palmrest.
WIFI_PWR_ON_AC=on
WIFI_PWR_ON_BAT=on
WIFI_PWR_ON_SAV=on

# Automatisierung: WLAN aus am LAN-Kabel, an ohne Kabel.
DEVICES_TO_DISABLE_ON_AC=""
DEVICES_TO_ENABLE_ON_BAT="wifi"

# Bluetooth bleibt beim Start aus, um Energie zu sparen.
RESTORE_DEVICE_STATE_ON_STARTUP=0
DEVICES_TO_DISABLE_ON_STARTUP="bluetooth"


# --- [ 4. NVME & PCIE THERMAL MANAGEMENT ] ----------------------------------
# Optimiert für die Crucial T500 SSD. Aggressives ASPM senkt Idle-Temps massiv.
PCIE_ASPM_ON_AC=powersave
PCIE_ASPM_ON_BAT=powersupersave
PCIE_ASPM_ON_SAV=powersupersave

# Optimiert das Intervall, in dem "schmutzige" Daten auf die SSD geschrieben werden.
# Ein höherer Wert (15s) erlaubt der Crucial T500, länger im Sleep-Mode zu bleiben,
# reduziert jedoch minimal die Datensicherheit bei einem plötzlichen Systemabsturz.
# Dies sorgt für ein "Gut" in der PowerTOP-Bewertung.
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=15

# Runtime Power Management (RPM): Versetzt ungenutzte PCIe/USB-Geräte dynamisch
# in den Tiefschlaf. "auto" ist essentiell, um PC10-States zu erreichen.
RUNTIME_PM_ON_AC=auto
RUNTIME_PM_ON_BAT=auto

# Thunderbolt-Controller (Denylist gegen Tiger Lake Hänger)
RUNTIME_PM_DENYLIST="00:0d.0 00:0d.2 00:0d.3"


# --- [ 5. GRAFIK (INTEL IRIS XE) ] ------------------------------------------
# Limits für die GPU. Auf Akku (BAT) wird der Boost deaktiviert (MAX = BOOST).
INTEL_GPU_MIN_FREQ_ON_AC=100
INTEL_GPU_MAX_FREQ_ON_AC=1300
INTEL_GPU_BOOST_FREQ_ON_AC=1300

INTEL_GPU_MIN_FREQ_ON_BAT=100
INTEL_GPU_MAX_FREQ_ON_BAT=800
INTEL_GPU_BOOST_FREQ_ON_BAT=1000


# --- [ 6. HARDWARE-PFLEGE & USB ] -------------------------------------------
# Battery Charge Thresholds: Schont den Akku (Start 40% / Stop 50%).
#START_CHARGE_THRESH_BAT0=40
#STOP_CHARGE_THRESH_BAT0=50

# USB Power Management: Maximale Ersparnis für C10-Support.
# Da FPR im BIOS aus ist, fokusieren wir uns auf Bluetooth & Webcam.
USB_AUTOSUSPEND=1
USB_EXCLUDE_AUDIO=1
USB_EXCLUDE_BTUSB=0      # Erlaubt BT-Schlaf (wichtig!)
USB_EXCLUDE_PHONE=0      # Verhindert, dass angeschlossene Handys den Schlaf blockieren
USB_ALLOWLIST=""         # Keine Ausnahmen, wir wollen volle Kontrolle


# --- [ 7. MULTIMEDIA / AUDIO ] ----------------------------------------------
# Versetzt den Audio-Controller in den Tiefschlaf (1 Sek. Timeout).
SOUND_POWER_SAVE_ON_AC=1
SOUND_POWER_SAVE_ON_BAT=1
SOUND_POWER_SAVE_CONTROLLER=Y

# ----------------------------------------------------------------------------
# KONFIGURATION ENDE - "May your fans be forever silent."

~
❯

 

[Karma]

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

Aber gerne doch - Fedora 43 auf T590 → super Dokumentation, sehr gute Installationsanleitung → alles funktioniert

~$ inxi -S
System:
  Host: Fedora Kernel: 6.18.7-200.fc43.x86_64 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.5.5 Distro: Fedora Linux 43 (KDE Plasma Desktop
    Edition)

 

[linrunner]

@ALL: ich bräuchte mal ein Meinungsbild von euch zu einem zu ändernden TLP-Default:

RESTORE_THRESHOLDS_ON_BAT=1

Das würde bewirken, dass standardmäßig jedesmal beim Abziehen des Netzteils die konfigurierten Schwellen wieder gesetzt werden. Zum Beispiel, falls man sie zuvor per tlp fullcharge rausgenommen hat, um für einen längeren mobilen Betrieb den Akku voll aufzuladen.

Wäre das für eure Anwendungsfälle sinnvoll? Bisher muss man das erst explizit konfigurieren.

# Dies sorgt für ein "Gut" in der PowerTOP-Bewertung.

Diese subjektive Einschätzung des PowerTOP Autors fand ich schon immer rätselhaft. Warum sparen 15s Ruhe auf der SSD mehr Energie als 60s?

# Thunderbolt-Controller (Denylist gegen Tiger Lake Hänger) RUNTIME_PM_DENYLIST="00:0d.0 00:0d.2 00:0d.3"

Interessant. Wie zeigen sich diese Hänger? Braucht es wirklich auch den einen USB-Controller in der DENYLIST?

0000:00:0d.0/power/control = auto (0x0c0330, USB controller, xhci_hcd)

 

[Crisser67]

Das würde bewirken, dass standardmäßig jedesmal beim Abziehen des Netzteils die konfigurierten Schwellen wieder gesetzt werden. Zum Beispiel, falls man sie zuvor per tlp fullchargerausgenommen hat, um für einen längeren mobilen Betrieb den Akku voll aufzuladen.

+1 Fände ich gut....meine Meinung....

 

[mcb]

TLP-Default:

RESTORE_THRESHOLDS_ON_BAT=1

Für mich gut, das habe ich schon seit Ewigkeiten drin.

 

[thickpad]

RESTORE_THRESHOLDS_ON_BAT=1
Das würde bewirken, dass standardmäßig jedesmal beim Abziehen des Netzteils die konfigurierten Schwellen wieder gesetzt werden. Zum Beispiel, falls man sie zuvor per tlp fullchargerausgenommen hat, um für einen längeren mobilen Betrieb den Akku voll aufzuladen.

Wäre das für eure Anwendungsfälle sinnvoll? Bisher muss man das erst explizit konfigurieren.

Einschätzung: Neutral.

Bitte berichtigen wenn falsch. tlp.service liest lediglich beim Bootvorgang die Konfiguration aus /etc/tlp.conf/ u. den Snippets aus tlp.d ein und wendet an, nicht aber bei Wechsel der Stromquelle oder auch beim Wakeup aus Standby oder?

Würd ich so interpretieren (System läuft seit gestern war mehrfach vom Netz und im S3 Standby):


In irgendeine Richtung muss man es sich halt merken, wenn ich jetzt wieder viel Mobil arbeite und ggfls. unterwegs aus ner PowerBank nachlade fände ich es nachteilig RESTORE_THRESHOLDS_ON_BAT=1 zu setzen weil ich dann evtl. nur restriktiv bis 50% gesetzt habe und aus der PowerBank dann weniger nachlade in einer Pause und das gar nicht merke. Also wärs mir evtl. für nen langen Tag wo ich vorher daheim mit tlp fullcharge auf 100% gehe und gegen Nachmittag nochmal nachlade evtl. lieber wenn es nicht auf die config Werte zurücksetzt aber das ist glaub ich schon sehr individuell.

Diese subjektive Einschätzung des PowerTOP Autors fand ich schon immer rätselhaft. Warum sparen 15s Ruhe auf der SSD mehr Energie als 60s?

Da hab ich mich versucht einzulesen. Das meiste was ich dazu gefunden habe war aus dem Zeitalter der magnetischen drehenden Scheiben wo zum Teil weitaus höhere Werte gesetzt wurden mit der Begründung das die Schreibköpfe dann länger nichts tun und in einer Ruheposition verbleiben und so Energie gespart wird. Ist das für NVME noch dahingehend relevant? Ich hab wenig Informationen dazu gefunden, nichts was mich komplett überzeugt hat, eine Seite die ich grad nicht mehr gefunden habe meinte es wäre besser den Wert kleiner zu setzen da eine NVME in dieser Zeitspanne eine viel größere Datenmenge nicht schreiben kann und es dann Spikes geben könnte wenn sie erst nach 60 Sekunden wieder schreibt und bin dann einfach mal auf den Wert vom PowerTop also 15 S gesprungen. Hast du da andere Infos zu?

Interessant. Wie zeigen sich diese Hänger? Braucht es wirklich auch den einen USB-Controller in der DENYLIST?

Bez dem TB-Controller
# Thunderbolt-Controller (Denylist gegen Tiger Lake Hänger) RUNTIME_PM_DENYLIST="00:0d.0 00:0d.2 00:0d.3"

u. dem USB-Controller
0000:00:0d.0/power/control = auto (0x0c0330, USB controller, xhci_hcd)

Ich hab einen Monitor über USB-C dran der ein Hub integriert hat und darüber LAN, Audio, Power, Maus, Tastatur und alles mögliche via USB-C an den Laptop verteilt. Ich bin ein gebranntes Kind mit dem Monitor weshalb ich bez. Energiesparen immer alles Blackliste was sich von meinem Endgerät dorthin verbindet weil ich in der Vergangenheit immer wieder mal Probleme hatte das der Monitor oder USB-Geräte dann nach S3-Suspend nicht wieder mit hochkamen oder dmesg Logs vollgespammt haben oder die Lan-Verbindung häufig ab/auf gebaut hat. Kann es nochmal ohne versuchen .

 

[linrunner]

Bitte berichtigen wenn falsch. tlp.service liest lediglich beim Bootvorgang die Konfiguration aus /etc/tlp.conf/ u. den Snippets aus tlp.d ein und wendet an, nicht aber bei Wechsel der Stromquelle oder auch beim Wakeup aus Standby oder?

Falsch geraten.

Beim jedem Wechsel der Stromquelle wird TLP aufgerufen (das auch stets die Config lesen muss, um arbeiten zu können). Ist die neue Stromquelle der Akku, dann findet RESTORE_THRESHOLDS_ON_BAT Berücksichtigung. Sonst hätte ja nicht fragen brauchen .

Auch beim Resume nach Suspend wird natürlich TLP aufgerufen und schaut ob die Stromquelle sich geändert hat. Last but not least wird beim Systemstart TLP aufgerufen und die Schwellen gesetzt.

Full Story siehe: https://linrunner.de/tlp/developers/architecture.html. Davon völlig unabhängig ist der tlp-pd, der lediglich die Möglichkeit zur "Handschaltung" am Desktop bereitstellt. Der Kern von TLP kommt ganz ohne eigenen Daemon aus.

Bezüglich RUNTIME_PM_DENYLIST: mein X1C9 hat andere Symptome und auch kein Dock. Es wacht in seltenen Fällen nicht mehr aus dem Suspend auf (Power LED blinkt munter weiter). Irgendein Kernel-Problem ...

 

[thickpad]

Herzlichen Dank,

jetzt nochmal für Dummies. Ein Fallbeispiel mit 2 Varianten:

1.

Ich habe den Laptop an AC gesteckt es sind restriktive Schwellen von 40/50 gesetzt, RESTORE_THRESHOLDS_ON_BAT=1 ist nicht gesetzt.

An AC löse ich mit tlp fullcharge eine temporäre Veränderung der Ladeschwellen auf 96/100 aus. TLP schreibt die Schwellen 96/100 direkt in die Hardware-Register des Akku-Controllers und läd voll. Das ist erst einmal "permanent", bis die Hardware einen neuen Befehl bekommt oder der Strom komplett weg ist vermute ich.

Später steck ich das Gerät ab, dann erkennt TLP den Wechsel zu BAT, setzt aber da RESTORE_THRESHOLDS_ON_BAT=1 nicht gesetzt ist die Schwellen nicht auf die Config Werte sondern behält die Hardware-Register ich bleibe also 96/100.

Interessant wird jetzt wenn ich dann Tagsüber das erste mal an AC gehe weil ich mich entscheide zu laden, weil dann TLP den Wechsel BAT-AC erkennt seine Config und Snippets liest und dann 96/100 mit 40/50 überschreibt und ich nur bis 50 Laden würde?=



_____________________________________________________________________________________________________________________

2.

Jetzt das gleiche vorgehen wieder, mit dem einzigen Unterschied: RESTORE_THRESHOLDS_ON_BAT=1 ist gesetzt.

Dann wäre der einzige Unterschied das sofort nach dem Abstecken Wechsel zu BAT getriggert wird und TLP also früher 40/50 (bereits beim Abstecken) in die Hardware-Register des Akku-Controllers schreibt. ALso nicht erst beim Anstecken später wenn ich entscheide zu laden sondern einen Energiequellenwechsel früher.


Fazit aus 1 und 2:

Ist diese Option wenn ich es jetzt richtig verstanden habe dann nicht komplett irrelevant ob und wie gesetzt weil ich in beiden Fällen dann die gesetzten Ladeschwellen aus der Config also in meinem Fall 40/50 Laden würde und ich für eine volle Ladung grundsätzlich erneut set fullcharge triggern müsste?

Bezüglich RUNTIME_PM_DENYLIST: mein X1C9 hat andere Symptome und auch kein Dock. Es wacht in seltenen Fällen nicht mehr aus dem Suspend auf (Power LED blinkt munter weiter). Irgendein Kernel-Problem ...

Ich lasse die Writeback jetzt mal so stehen, mir ist einfach nicht klar ob und was sich da tatsächlich ändert, wirkt nach ner sehr homöpathischen Option evtl war das früher eher mit anlaufenden mechanischen Schreibköpfen relevant:

MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=15

Ach Spannend das du auch ein X1C9 hast! Ne Aufwachen ist kein Problem bislang, hast du es im Bios auf Modern Standby oder S3 Suspend? Aber ich hab das Gerät auch erst wenige Tage, werde jetzt mal testweise den Thunderbolt-Controller und den USB-Controller aus der Blacklist von tlp auskommentieren und gucken was sich tut. .

 

[Volvo-Berti]

@KB19 ach ja, die L-Reihe ...
Auch für Bookworm gibt es 1.9.1 als Backport!

@Volvo-Berti wenn Du TLP möchtest, muss der power-profiles-daemon weichen. Das ist gewollt.
Nimm TLP 1.9.1 aus dem PPA, das ersetzt ihn vollständig:

Ubuntu — TLP 1.10.0 documentation

moin, das habe ich soeben gemacht. tlp läuft auch, allerdings finde ich grad nciht mehr, wo und wie ich die Ladeschwellen sehen bzw. einstellen könnte. Ich kann mich nur erinnern, das es eine config war....

 

[linrunner]

Ist diese Option wenn ich es jetzt richtig verstanden habe dann nicht komplett irrelevant ob und wie gesetzt weil ich in beiden Fällen dann die gesetzten Ladeschwellen aus der Config also in meinem Fall 40/50 Laden würde und ich für eine volle Ladung grundsätzlich erneut set fullcharge triggern müsste?

Nein.

Mit RESTORE_THRESHOLDS_ON_BAT=0 machst Du zum Vollladen vor der Reise ein tlp fullcharge (a). Wenn Du zurück bist, benötigst Du vor dem Laden zum Erreichen des alten Ladeschwellen-Zustands tlp setcharge(b).

Mit RESTORE_THRESHOLDS_ON_BAT=1 entfällt (b), denn es passiert beim Abstecken des Netzteils automatisch.

Wenn deine Reisen länger dauern und Du währenddessen mehrfach voll aufladen möchtest, könnte RESTORE_THRESHOLDS_ON_BAT=0 die passendere Variante sein.

Statt langer Texte empfehle ich ausprobieren!

------------------------------
@Volvo-Berti bei der Deinstallation bleibt die Konfigurationsdatei stehen. Ebenso bei der erneuten Installation, sofern Du die richtige Antwort gibst (siehe oben). Zudem speichert die Hardware die Schwellwerte sowieso, auch ohne TLP. Ansonsten schaust Du kurz in die Konfigurationsanleitung.

 

[mcb]

Wenn deine Reisen länger dauern und Du währenddessen mehrfach voll aufladen möchtest, könnte RESTORE_THRESHOLDS_ON_BAT=0 die passendere Variante sein.

Oder man ändert die Ladeschwellen in der config, so würde ich das machen.

 

[ksk_halo]

Ich bekomme beim Versuch den Akku zu kalibrien folgen Meldung. Der Akku ist voll aufgeladen

Setting temporary charge thresholds for BAT0:
start = 96
stop = 100 (no change)
Error: discharge BAT0 malfunction -- check your hardware (battery, charger).
Battery recalibration aborted.
Ist ein T14 Gen1 AMD, Bios ist aktuell


Hier mal noch das Ergebnis vom Batteriestatus

--- TLP 1.6.1 --------------------------------------------

+++ Battery Care
Plugin: thinkpad
Supported features: charge thresholds, recalibration
Driver usage:
* natacpi (thinkpad_acpi) = active (charge thresholds, recalibration)
Parameter value ranges:
* START_CHARGE_THRESH_BAT0/1: 0(off)..96(default)..99
* STOP_CHARGE_THRESH_BAT0/1: 1..100(default)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer = LGC
/sys/class/power_supply/BAT0/model_name = 5B10W139
/sys/class/power_supply/BAT0/cycle_count = 80
/sys/class/power_supply/BAT0/energy_full_design = 50500 [mWh]
/sys/class/power_supply/BAT0/energy_full = 39120 [mWh]
/sys/class/power_supply/BAT0/energy_now = 39120 [mWh]
/sys/class/power_supply/BAT0/power_now = 0 [mW]
/sys/class/power_supply/BAT0/status = Full

/sys/class/power_supply/BAT0/charge_control_start_threshold = 96 [%]
/sys/class/power_supply/BAT0/charge_control_end_threshold = 100 [%]
/sys/class/power_supply/BAT0/charge_behaviour = [auto] inhibit-charge force-discharge

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

 

[linrunner]

@ksk_halo sobald Du den KI Teil aus deinem Post entfernt hast, befasse ich mich gerne mit deinem Problem.
-> Danke.

Die Ausgabe von tlp recalibrate scheint mir nicht vollständig zu sein. Da fehlt die Fortschrittsanzeige bei der Initialisierung. Die sieht so aus:

Initiating discharge of battery BAT0 ...

Für mich wichtig ist die genaue Anzahl der Punkte. Nimm bitte das Kommando

sudo tlp discharge

und zeige die gesamte Ausgabe samt Befehl bis zum nächsten Shell Prompt.

Ausserdem bitte noch:

tlp-stat -s

 

[ksk_halo]

Jetzt hat er nach tlp recalibrate begonnen zu entladen.
Das sieht dann jetzt erst mal nach normaler Funktion aus.

Currently discharging battery BAT0:
voltage = 12751 [mV]
remaining capacity = 38490 [mWh]
remaining percent = 98 [%]
remaining time = 227 [min]
power = 10162 [mW]
state = Discharging
force-discharge = 1
Press Ctrl+C to cancel.

 

[linrunner]

@ksk_halo Falls es nochmal mit "discharge malfunction" abbricht, brauche ich die Ausgabe mit den Punkten. Sobald er entlädt, wird die leider durch die Fortschrittsanzeige ersetzt. Du musst es jetzt aber nicht versuchen zu reproduzieren. Nur wenn es beim nächsten Mal auftritt.

ps. und hol dir bitte die aktuelle Version 1.9.1 aus dem PPA. Die Version 1.6.1 aus Ubuntu 24.04 ist steinalt.

 

[Volvo-Berti]

...
------------------------------
@Volvo-Berti bei der Deinstallation bleibt die Konfigurationsdatei stehen. Ebenso bei der erneuten Installation, sofern Du die richtige Antwort gibst (siehe oben). Zudem speichert die Hardware die Schwellwerte sowieso, auch ohne TLP. Ansonsten schaust Du kurz in die Konfigurationsanleitung.

so ist das in meiner tlp.conf eingestellt: aber muss das # nicht weg?

# Battery charge level below which charging will begin.
#START_CHARGE_THRESH_BAT0=60
# Battery charge level above which charging will stop.
#STOP_CHARGE_THRESH_BAT0=80

# BAT1: Secondary battery (primary on some laptops)
# Default: <none>

# Battery charge level below which charging will begin.
#START_CHARGE_THRESH_BAT1=60
# Battery charge level above which charging will stop.
#STOP_CHARGE_THRESH_BAT1=80

 

[linrunner]

aber muss das # nicht weg?

Warum fragst Du, wenn Du's schon weißt?

 

[Volvo-Berti]

Warum fragst Du, wenn Du's schon weißt?

wäre ich mir sicher gewesen, hätte ich nicht gefragt.... was ja für mich zeigt, dass es eben doch eine Änderung geben hat in der tlp.conf nach dem Update auf 1.9.1

 

[ksk_halo]

Currently discharging battery BAT0 to 0% (0 mWh):
voltage = 10977 [mV]
remaining energy = 960 [mWh]
remaining percent = 2.3 [%]
remaining time = 14 [min]
power = 3896 [mW]
status = Discharging
force-discharge = 1
Press Ctrl+C to cancel.
Error: battery BAT0 discharge was aborted early -- check your hardware (battery, charger).

Das hat er jetzt zum zweiten mal beim Etladen zurückgemeldet. Kann es sein dass die gespeicherte Anzeige einfach nicht stimmt um die Restladung noch zu hoch ist und die Abschaltung zu früh erfolgt.

Nach dem erstem mal Entalden und dem anschliessendem Laden war die angezeigte Restkapazität höher als vorher.
Stieg an von 77,5% auf 81%

 

[linrunner]

was ja für mich zeigt, dass es eben doch eine Änderung geben hat in der tlp.conf nach dem Update auf 1.9.1

Hätte das Paketupgrade eine neue tlp.conf installiert, dann stünden darin die Defaultschwellen 75/80. Ein Paketupgrade wird niemals einzelne Zeilen ändern (ist auch nicht vorgesehen). Daher müssen die Werte 60/80 von dir stammen und Du hast die Zeilen auch selbst auskommentiert.

@ksk_halo das liegt am Akku. Manche Akku-Probleme können durch eine Rekalibration nicht behoben werden.