Linux [TLP 1.10 Beta 1] Der Test Thread

Linux Betriebssystem

linrunner

Ubuntuversteher
Themenstarter
Registriert
22 Juni 2007
Beiträge
14.045
Update 27.03.2026: 1.10.0-beta.1
Update 07.04.2026: 1.10.0-beta.2


Hi,

Ihr habt letztes Mal sehr engagiert getestet, davon hat die Qualität des Release 1.9 deutlich profitiert. Deshalb dürft Ihr diesmal wieder ran! ;)

Bevor der offizielle Beta-Test beginnt, sollt Ihr zunächst den letzten/laufenden Entwicklungsstand (main Branch = Alpha Version) ausprobieren. Scheut Euch nicht vor einer Alpha-Version, der main Branch wird von mir bereits ausführlich getestet und ich verwende ihn auf allen meinen ThinkPads produktiv.

Was kommt neu mit 1.10?

TLP Profiles Daemon (tlp-pd)

tlp-pd wurde sehr positiv aufgenommen, die Einführung ist nicht zuletzt dank Eurer tatkräftigen Mithilfe im Test reibungslos gelungen. Für 1.10 hab ich mich an die Feinarbeit gemacht und den Wunsch umgesetzt, den beiden Stromquellen andere Profile zuweisen zu können. Beispielsweise bewirkt
TLP_PROFILE_AC=BAL
TLP_PROFILE_BAT=SAV
dass am Netzteil balanced und im Akkubetrieb power-saver wirkt.

Bei der Gelegenheit wurde noch mehr aufgeräumt:
  • TLP_DEFAULT_MODE ist umbenannt in TLP_PROFILE_DEFAULT (TLP versteht jedoch weiterhin den alten Parameter)
  • TLP_PERSISTENT_DEFAULT wird mit 1.11 rausfliegen. TLP_AUTO_SWITCH=0 zusammen mit TLP_PROFILE_DEFAULT bewirkt dasselbe, nämlich beim Systemstart wird das angegebene Profil angesteuert – und bei Wechsel der Stromquelle nicht automatisch umgeschaltet
Ausserdem wurde tlp-pd umgeschrieben, die veraltete Bibliothek python-dbus musste gehen.

Ladeschwellen
Nur eine Kleinigkeit aus der Kategorie Komfort. Diese Option ist nun standardmäßig aktiv: RESTORE_THRESHOLDS_ON_BAT=1
Wenn das Ladegerät abgezogen wird, beispielsweise nach einem Vollladen per tlp fullcharge, werden die konfigurierten Ladeschwellenwerte automatisch wiederhergestellt. Wer das nicht möchte, setzt RESTORE_THRESHOLDS_ON_BAT=0.

Ausserdem wurde die ThinkPad Modellerkennung vereinfacht und dabei ein Problem mit Libreboot auf dem T580 gefixt:

Grafik
Unterstützung von SLPC und Frequenzlimits für Intel Xe bzw. Arc GPUs (ab Kernel 6.8, besser der Neueste):
  • INTEL_GPU_POWER_PROFILE_ON_AC/BAT/SAV – neu, nur für Xe
  • INTEL_GPU_MIN/MAX_FREQ_ON_AC/BAT/SAV – gab es schon immer für den i915 Treiber
Der zuständige (experimentelle) Treiber xe ist allerdings recht schüchtern, lädt auch mit allerneuestem Kernel standardmäßig nicht und möchte gebeten werden. Das Arch Wiki hilft. Ist der Treiber aktiv, sieht tlp-stat -g so aus:
+++ Intel Graphics
/sys/class/drm/card0/device/driver = xe
/sys/class/drm/card0/device/tile0/gt0/freq0/power_profile = base [power_saving]
Für AMD GPUs gibt es nun einen separaten Parameter für's power-saver Profil: RADEON_DPM_PERF_LEVEL_ON_SAV

Weitere Neuerungen
Siehe das vollständige Changelog.

Testziele
Hier gehts mir auch darum, eventuelle Regressionen – tut mit 1.9.1 aber mit 1.10 nicht mehr – zu finden.
  1. Klappt das Umschalten der TLP Profile weiterhin reibungslos, sowohl per Mausklick als auch automatisch und funktioniert TLP_PROFILE_AC/BAT?
  2. Wirkt INTEL_GPU_POWER_PROFILE_ON_AC/BAT/SAV wenn der xe Treiber geladen ist
  3. Werden die Ladeschwellen unverändert erkannt (tlp-stat -b)?
  4. Läuft sudo tlp discharge auf euren ThinkPads sauber an? Ihr müsst es nicht durchlaufen lassen, nach dem Start einfach mit Ctrl-C abbrechen. Falls Ihr bis auf 0% entladen möchtet, sind wg. UPower Vorkehrungen nötig: https://linrunner.de/tlp/faq/battery.html#faq-discharge-shutdown
Eure bisherige Konfiguration solltet Ihr für den Test beibehalten und ggf. ergänzen.

Ich empfehle übrigens, eure individuelle Konfiguration von /etc/tlp.conf nach /etc/tlp.d/meine.conf zu verlagern, also nur die angepassten Sachen. Dann kann sie nicht durch eine versehentlich falsche Antwort an den Paketmanager hops gehen.

Falls jemand ein Lenovo Non-ThinkPad Modell (auch Thinkbook) hat, bin ich übrigens auch interessiert - wenn ein Kernel >= 6.17 läuft.
Ebenso ThinkPads mit Coreboot oder Libreboot.
EDITH sagt: auch andere Fabrikate sind natürlich im Test willkommen.

Beta Pakete (Arch, Debian, Fedora, Ubuntu)
Siehe Download Seite.

Bei Debian/Ubuntu könnt (solltet) Ihr eure vorhandene Konfiguration übernehmen, in dem ihr während der Paketinstallation beim Prompt "Configuration file /etc/tlp.conf" mit 'N' (für "keep your currently-installed version") antwortet.

Testschritte / Benötigte Terminalausgaben
  1. Nach der Installation den Rechner bitte neu starten
  2. Am Desktop nacheinander die drei Profile anklicken und jedesmal die vollständige Ausgabe von
    Bash:
    sudo tlp-stat
    zeigen
  3. Am Desktop prüfen ob beim Wechsel vom Netzteil zum Akkubetrieb und zurück das Profil entsprechend wechselt, d.h. Netzteil = performance, Akku = balanced (oder das was Ihr abweichend konfiguriert habt, s.o.)
  4. Nur falls ihr tlp-pd nicht installieren möchtet/könnt oder es mit eurem Desktop nicht funktioniert: bitte manuell per tlp performance/balanced/power-saver umschalten und danach jeweils sudo tlp-stat zeigen
Aufgrund der Längenbegrenzung des Forumseditors die Ausgaben bitte per Paste-Service - vorzugsweise https://gist.github.com/

Fehlerberichte
Wenn etwas nicht wie erwartet funktionieren sollte oder Fragen sind → bitte hier im Thread melden.

Abgrenzung: alles was mit TLP Version < 1.10 zu tun hat, gehört hier nicht rein, sondern in den regulären Support-Thread.

Infos
 
Zuletzt bearbeitet:
@Karma danke für den Hinweis. Allerdings funktionierten bei mir soeben beide im Post enthaltenen Links korrekt. In deinem Post ist der zweite Link falsch.
 
Hey Linrunner,

ich hab mal die Deb Pakete aus dem Download Bereich mit dpkg auf nem aktuellen Devuan 6 installiert. Leider ließ sich tlp-pd unter SysV nicht problemlos starten. Bekomme diese Fehlermeldung:
sudo service tlp-pd start
grep: /etc/init.d/tlp-pd: Datei oder Verzeichnis nicht gefunden
tlp-pd: unrecognized service

Unglücklicherweise bin ich nicht ganz so firm mit SysV Init Scripts. Hab das mal gegoogelt im Forum aber nichts wirklich dazu gefunden. Ich denke, dass es evtl daran liegt, da tlp-pd ein noch recht junges Paket ist. Hast du zufällig ein Template dafür irgendwo in ner Schublade die ich ins etc werfen kann? ppd habe ich natürlich vorher deinstalliert und auch sonst zwischendurch neugestartet.

Hier noch die vollständige Ausgabe.
 
@Ambroisus: falls Du das wirklich willst, musst Du selbst forschen. Mein tlp-pd Paket, genauso wie das offizelle 1.9.1 Paket in Debian, unterstützt SysV nicht. Das gilt übrigens genauso für power-profile-daemon und tuned-ppd. Non-Systemd ist im Jahr 2026 eine Nische für Liebhaber, dafür nehm ich mir keine Zeit.

Das Devuan tlp-pd Paket 1.9.1 hab ich eben kurz angeschaut. Da wurde nichts gepatcht, wird also auch nicht laufen.

Es gibt diverse Distris und mehrere unterschiedliche (teils von SysV abgeleitete) Init-Systeme, die bauen dann ihre eigenen Skripte in die Pakete. EDITH sagt: das Skripting für Suspend/Resume ist ebenfalls Sache der Distri.

Für Void-Linux hat kürzlich jemand eine Installationsanleitung bereitgestellt. Im Prinzip könnte es also gehen. Viel Erfolg!
 
@Arminius
Geht denn 1.9.1 unter Devuan?

tlp performance/balanced/power-saver
Braucht bei mir root Rechte.

Puh: die jährliche Rekalibrierung durchgeführt! UPower ist ein Krampf...

Code:
Currently discharging battery BAT0 to 0% (0 mWh):
voltage            =  12352 [mV]
remaining energy   =     30 [mWh]
remaining percent  =    0.1 [%]
remaining time     =      0 [min]
power              =  18305 [mW]
status             = Discharging
force-discharge    = 1
Press Ctrl+C to cancel.
Done: battery BAT0 discharge complete.
Charging starts now. For a complete recalibration
keep AC connected until the battery is fully charged.
root@t14:/home/marc/tmp/tlp/log# tlp-stat -s
--- TLP 1.10.0-alpha.1_ad5e9b6 --------------------------------------------

+++ System Info
System         = LENOVO ThinkPad T14 Gen 4 21K4S0XH04
BIOS           = LENOVO R2FET67W (1.47 )
EC firmware    = 1.33
OS release     = Debian GNU/Linux 13 (trixie)
Kernel         = 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64
/proc/cmdline  = BOOT_IMAGE=/vmlinuz-6.12.73+deb13-amd64 root=/dev/mapper/vg-root ro quiet
Init system    = systemd 257
Boot mode      = UEFI
Suspend mode   = [s2idle]

+++ TLP Status
tlp            = enabled, last run: 02:51:01 PM, 910 sec(s) ago
tlp-rdw        = enabled
tlp-pd         = enabled, running
TLP profile    = performance/AC
Power source   = AC

Logs mit Kernel 6.12:
jeweils mit 'sudo tlp xxx' geschaltet:

Soweit funktioniert alles.
 
T480, Debian Forky mit Cinnamon (Live-System mit Persistenz):
✅ funktioniert soweit alles, inkl. sudo tlp discharge

C13 Yoga, Debian Trixie mit Cinnamon und Backport-Kernel:
❌ funktioniert fast alles, aber Fehler bei sudo tlp discharge

Hab es an beiden Ladebuchsen mit zwei Original-Netzteilen probiert:
Bash:
# Netzteil 1, rechte Buchse
user@user-morphius:~$ sudo tlp discharge
Initiating discharge of battery BAT0 ..
/usr/sbin/tlp: 826: 1: not found
Error: discharge BAT0 initialization malfunction after 2 second(s) -- check your hardware (battery, charger).

# Netzteil 1, linke Buchse
user@user-morphius:~$ sudo tlp discharge
Initiating discharge of battery BAT0 ...
/usr/sbin/tlp: 826: 1: not found
Error: discharge BAT0 initialization malfunction after 3 second(s) -- check your hardware (battery, charger).

# Netzteil 2, rechte Buchse
user@user-morphius:~$ sudo tlp discharge
Initiating discharge of battery BAT0
/usr/sbin/tlp: 826: 1: not found
Error: discharge BAT0 initialization malfunction after 0 second(s) -- check your hardware (battery, charger).

# Netzteil 2, linke Buchse
user@user-morphius:~$ sudo tlp discharge
Initiating discharge of battery BAT0
/usr/sbin/tlp: 826: 1: not found
Error: discharge BAT0 initialization malfunction after 0 second(s) -- check your hardware (battery, charger).
Dass es 2 bis 3 Sekunden dauert ist nur beim ersten Einstecken nach einem Neustart an der jeweiligen Buchse so. Ziehe ich das Netzteil ab und stecke es wieder rein werden direkt 0 Sekunden angezeigt beim nächsten discharge-Versuch.
 
Werden die Ladeschwellen unverändert erkannt (tlp-stat -b)?
Ja
Code:
Currently discharging battery BAT0 to 92% (48787 mWh):
voltage            =  17505 [mV]
remaining energy   =  52980 [mWh]
remaining percent  =   99.9 [%]
remaining time     =     58 [min]
power              =   4271 [mW]
status             = Discharging
force-discharge    = 1
Press Ctrl+C to cancel.
^C Cancelled.
root@t14:~# tlp-stat -s
--- TLP 1.10.0-alpha.1_ad5e9b6 --------------------------------------------

+++ System Info
System         = LENOVO ThinkPad T14 Gen 4 21K4S0XH04
BIOS           = LENOVO R2FET67W (1.47 )
EC firmware    = 1.33
OS release     = Debian GNU/Linux 13 (trixie)
Kernel         = 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64
/proc/cmdline  = BOOT_IMAGE=/vmlinuz-6.12.73+deb13-amd64 root=/dev/mapper/vg-root ro quiet
Init system    = systemd 257
Boot mode      = UEFI
Suspend mode   = [s2idle]

+++ TLP Status
tlp            = enabled, last run: 05:59:56 PM, 4 sec(s) ago
tlp-rdw        = enabled
tlp-pd         = enabled, running
TLP profile    = balanced/BAT
Power source   = AC

root@t14:~# tlp-stat -s --cdiff
--- TLP 1.10.0-alpha.1_ad5e9b6 --------------------------------------------

+++ Configured Settings (only differences to defaults):
/etc/tlp.d/00-amd.conf L0002: TLP_AUTO_SWITCH="1"
/etc/tlp.d/00-amd.conf L0003: TLP_PROFILE_AC="BAL"
/etc/tlp.d/00-amd.conf L0004: TLP_PROFILE_BAT="SAV"
/etc/tlp.d/00-amd.conf L0005: DISK_DEVICES="nvme0n1 sda sdb"
/etc/tlp.d/00-amd.conf L0006: AMDGPU_ABM_LEVEL_ON_BAT="0"
/etc/tlp.d/00-amd.conf L0007: AMDGPU_ABM_LEVEL_ON_SAV="0"
/etc/tlp.d/00-amd.conf L0008: WIFI_PWR_ON_AC="on"
/etc/tlp.d/00-amd.conf L0009: SOUND_POWER_SAVE_CONTROLLER="N"
/etc/tlp.d/00-amd.conf L0010: RUNTIME_PM_ON_AC="auto"
/etc/tlp.d/00-amd.conf L0011: TLP_PROFILE_DEFAULT="BAL"
/etc/tlp.d/00-amd.conf L0012: DEVICES_TO_DISABLE_ON_STARTUP="bluetooth"
/etc/tlp.d/00-amd.conf L0013: START_CHARGE_THRESH_BAT0="60"
/etc/tlp.d/00-amd.conf L0014: STOP_CHARGE_THRESH_BAT0="80"
/etc/tlp.d/00-amd.conf L0015: DEVICES_TO_DISABLE_ON_BAT_NOT_IN_USE="bluetooth"
/etc/tlp.d/00-amd.conf L0016: CPU_DRIVER_OPMODE_ON_AC="active"
/etc/tlp.d/00-amd.conf L0017: CPU_DRIVER_OPMODE_ON_BAT="active"
/etc/tlp.d/00-amd.conf L0018: CPU_DRIVER_OPMODE_ON_SAV="active"
/etc/tlp.d/00-amd.conf L0019: DEVICES_TO_DISABLE_ON_LAN_CONNECT="wifi wwan"
/etc/tlp.d/00-amd.conf L0020: DEVICES_TO_ENABLE_ON_LAN_DISCONNECT="wifi"
/etc/tlp.d/00-amd.conf L0021: CPU_BOOST_ON_AC="1"
/etc/tlp.d/00-amd.conf L0022: CPU_BOOST_ON_BAT="1"
/etc/tlp.d/00-amd.conf L0023: CPU_BOOST_ON_SAV="0"
/etc/tlp.d/00-amd.conf L0024: CPU_SCALING_GOVERNOR_ON_AC="powersave"
/etc/tlp.d/00-amd.conf L0025: CPU_SCALING_GOVERNOR_ON_BAT="powersave"
/etc/tlp.d/00-amd.conf L0026: CPU_SCALING_GOVERNOR_ON_SAV="powersave"

+++ System Info
System         = LENOVO ThinkPad T14 Gen 4 21K4S0XH04
BIOS           = LENOVO R2FET67W (1.47 )
EC firmware    = 1.33
OS release     = Debian GNU/Linux 13 (trixie)
Kernel         = 6.12.73+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17) x86_64
/proc/cmdline  = BOOT_IMAGE=/vmlinuz-6.12.73+deb13-amd64 root=/dev/mapper/vg-root ro quiet
Init system    = systemd 257
Boot mode      = UEFI
Suspend mode   = [s2idle]

+++ TLP Status
tlp            = enabled, last run: 05:59:56 PM, 10 sec(s) ago
tlp-rdw        = enabled
tlp-pd         = enabled, running
TLP profile    = balanced/BAT
Power source   = AC

Umschalten
Code:
TLP_AUTO_SWITCH=1
TLP_PROFILE_AC="BAL"
TLP_PROFILE_BAT="SAV"
geht auch. Puh jetzt Feierabend. ;-)
 
Mein tlp-pd Paket, genauso wie das offizelle 1.9.1 Paket in Debian, unterstützt SysV nicht. Das gilt übrigens genauso für power-profile-daemon und tuned-ppd. Non-Systemd ist im Jahr 2026 eine Nische für Liebhaber, dafür nehm ich mir keine Zeit.
Hey, ja das verstehe ich natürlich sehr gut. Tatsächlich hatte ich bisher nie den Bedarf gehabt an zusätzlichen Init Scripts. Die letzte mir bekannte Distro, die SysV anbot war MX Linux mit dem XFCE Spin. Diese gibt es auch heute noch ohne systemD. Hier wurde es letztes Jahr mal bekanntgegeben. So viel dazu.

Geht denn 1.9.1 unter Devuan?
In Bezug auf tlp-pd: Nein, denn ..
Das Devuan tlp-pd Paket 1.9.1 hab ich eben kurz angeschaut. Da wurde nichts gepatcht, wird also auch nicht laufen.

Ich werde mich also da nochmal reinlesen und schauen ob ich das selbst schreibe oder mir da was zurecht basteln kann.

Für Void-Linux hat kürzlich jemand eine Installationsanleitung bereitgestellt. Im Prinzip könnte es also gehen. Viel Erfolg!
Die hab ich neulich auf deiner Seite auch geblitzt. Ich hab die Version 1.9.1 btw auch am Laufen, ganz ohne händisches Eingreifen. Das Main Repo ist erstaunlich up tp date und hinkt nicht so lange hinter deinen Releases nach. Sieh hier:


Code:
$ xbps-query tlp
architecture: x86_64
changelog: https://raw.githubusercontent.com/linrunner/TLP/main/changelog
conf_files:
        /etc/tlp.conf
        /etc/tlp.d/00-template.conf
conflicts:
        laptop-mode>=0
        perl-Unicode-Tussle>=0
filename-sha256: 8915be9209665b44d4ebea3a662348d357f13a5afb2e98b07bc3887efda3afe0
filename-size: 103KB
homepage: https://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html
install-date: 2026-01-10 01:00 CET
install-script: 825B
installed_size: 778KB
license: GPL-2.0-or-later
maintainer: Orphaned <orphan@voidlinux.org>
metafile-sha256: 7a34b526c042b2ee64287faa713873fc1849128b3498c64195dc6fa995348368
pkgname: tlp
pkgver: tlp-1.9.1_1
provides:
        cmd:bluetooth-1.9.1_1
        cmd:run-on-ac-1.9.1_1
        cmd:tlp-1.9.1_1
        cmd:tlp-stat-1.9.1_1
remove-script: 824B
repository: https://repo-de.voidlinux.org/current
run_depends:
        hdparm>=0
        bash>=0
        iw>=0
        util-linux>=0
        ethtool>=0
        perl>=0
short_desc: Advanced power management tool for Linux
source-revisions: tlp:866b312e932
sourcepkg: tlp
state: installed



$ xbps-query tlp-pd
architecture: x86_64
changelog: https://raw.githubusercontent.com/linrunner/TLP/main/changelog
conf_files:
        /etc/tlp-pd.dbus.conf
conflicts:
        power-profiles-daemon>=0
filename-sha256: 4dfdc6f2830729e9843d769f559cb13352dea4692a8d27acabf5672bfe4b93e5
filename-size: 14KB
homepage: https://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html
install-date: 2026-01-10 01:00 CET
installed_size: 53KB
license: GPL-2.0-or-later
maintainer: Orphaned <orphan@voidlinux.org>
metafile-sha256: 0f3751f985334eddff805cf68f3d97a9475012a41582c648107aa184bbf477b1
pkgname: tlp-pd
pkgver: tlp-pd-1.9.1_1
provides:
        cmd:tlp-pd-1.9.1_1
        cmd:tlpctl-1.9.1_1
repository: https://repo-de.voidlinux.org/current
run_depends:
        tlp>=0
        python3-dbus>=0
        python3-gobject>=0
        polkit>=0
short_desc: TLP Profiles Daemon
source-revisions: tlp:866b312e932
sourcepkg: tlp
state: installed
 
❌ funktioniert fast alles, aber Fehler bei sudo tlp discharge

Hab es an beiden Ladebuchsen mit zwei Original-Netzteilen probiert:
Nachtrag: Der Befehl wird zwar abgebrochen, aber wenn ich danach watch sudo tlp-stat -b aufrufe, steht da die ganze Zeit "Discharging", was sich erst zu "Charging" ändert, wenn ich das Netzteil abziehe und neu reinstecke.

Weiterer Nachtrag: Durch diesen Fehler wird auch die (obere) Ladeschwelle nicht mehr gehalten. Hab sie bei 90 Prozent eingestellt, was ich auch sehe, wenn ich cat /sys/class/power_supply/BAT0/charge_control_end_threshold mache. Aber bei /sys/class/power_supply/BAT0/current_now steht in der Ausgabe von sudo tlp-stat -b nicht 0 [mA], sodass über 90 Prozent geladen wird. Erst ein Neustart vom Gerät führt dazu, dass die (obere) Ladeschwelle wieder gehalten wird.
 
Zuletzt bearbeitet:
Unter Debian 12 gibt es keine Schaltflächen unter Gnome. Der Rest funktioniert. Logs kann ich erst in ein paar Tagen posten.
Mit 1.9.x waren die Schaltflächen noch vorhanden.
 
❌ funktioniert fast alles, aber Fehler bei sudo tlp discharge
Ist eigentlich nur ein simpler Typo, ich möchte den Code aber noch etwas überarbeiten. Ich bin jetzt erstmal verreist und sage Bescheid, sobald ich eine neue Version bereitstelle.

Nachtrag: Der Befehl wird zwar abgebrochen, aber wenn ich danach watch sudo tlp-stat -b aufrufe, steht da die ganze Zeit "Discharging", was sich erst zu "Charging" ändert, wenn ich das Netzteil abziehe und neu reinstecke.
Kannst Du mal schauen, ob direkt nach dem Fehler/Abbruch charge_behaviour auf force-discharge stehen bleibt?

Weiterer Nachtrag: Durch diesen Fehler wird auch die (obere) Ladeschwelle nicht mehr gehalten. Hab sie bei 90 Prozent eingestellt, was ich auch sehe, wenn ich cat /sys/class/power_supply/BAT0/charge_control_end_threshold mache. Aber bei /sys/class/power_supply/BAT0/current_now steht in der Ausgabe von sudo tlp-stat -b nicht 0 [mA], sodass über 90 Prozent geladen wird. Erst ein Neustart vom Gerät führt dazu, dass die (obere) Ladeschwelle wieder gehalten wird.
Ich frage mich schon länger, wer bei Google diese schräge EC-Firmware verzapft hat.

Unter Debian 12 gibt es keine Schaltflächen unter Gnome. Der Rest funktioniert. Logs kann ich erst in ein paar Tagen posten.
Mit 1.9.x waren die Schaltflächen noch vorhanden.
Danke! Schau ich mir an.

@RomanX Danke! Hast Du schon die sbin-bin-Thematik angeschaut? Mein Vorschlag für tlp.spec wäre:
Code:
%prep
%autosetup -n tlp-%{gittag}

%build
%make_build \
  TLP_ULIB=%{_udevrulesdir}/.. \
  TLP_SBIN=%{_bindir}

%install
%make_install \
  TLP_SDSL=%{_unitdir}/../system-sleep \
  TLP_NMDSP=%{_prefix}/lib/NetworkManager/dispatcher.d \
  TLP_NO_INIT=1 \
  TLP_WITH_ELOGIND=0 \
  TLP_SYSD=%{_unitdir} \
  TLP_ULIB=%{_udevrulesdir}/.. \
  TLP_SBIN=%{_bindir}
 
Kannst Du mal schauen, ob direkt nach dem Fehler/Abbruch charge_behaviour auf force-discharge stehen bleibt?

Nach dem Fehler:
Bash:
--- TLP 1.10.0-alpha.1_ad5e9b6 --------------------------------------------

+++ Battery Care
Plugin: cros-ec
Supported features: charge threshold, chargeonce, discharge, recalibrate
Driver usage:
* natacpi (cros_charge-control) = active (charge threshold, force-discharge) - EC cmd v2
Parameter value ranges:
* STOP_CHARGE_THRESH_BAT0/1:   1..100(default)

+++ Battery Status: BAT0
/sys/class/power_supply/BAT0/manufacturer                   = Sunwoda
/sys/class/power_supply/BAT0/model_name                     = L19D4PG
/sys/class/power_supply/BAT0/cycle_count                    =    120
/sys/class/power_supply/BAT0/charge_full_design             =   6650 [mAh] ( 54623 mWh)
/sys/class/power_supply/BAT0/charge_full                    =   5903 [mAh] ( 48487 mWh)
/sys/class/power_supply/BAT0/charge_now                     =   5128 [mAh] ( 42121 mWh)
/sys/class/power_supply/BAT0/current_now                    =    703 [mA]  (  5774 mW)
/sys/class/power_supply/BAT0/status                         = Discharging

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

Charge                                                      =   86.9 [%]
Capacity                                                    =   88.8 [%]

Bleibt auch, wenn ich das Netzteil abziehe, neu reinstecke und dadurch zu "Charging" gewechselt wird:
Bash:
--- TLP 1.10.0-alpha.1_ad5e9b6 --------------------------------------------

+++ Battery Care
Plugin: cros-ec
Supported features: charge threshold, chargeonce, discharge, recalibrate
Driver usage:
* natacpi (cros_charge-control) = active (charge threshold, force-discharge) - EC cmd v2
Parameter value ranges:
* STOP_CHARGE_THRESH_BAT0/1:   1..100(default)

+++ Battery Status: BAT0
/sys/class/power_supply/BAT0/manufacturer                   = Sunwoda
/sys/class/power_supply/BAT0/model_name                     = L19D4PG
/sys/class/power_supply/BAT0/cycle_count                    =    120
/sys/class/power_supply/BAT0/charge_full_design             =   6650 [mAh] ( 57230 mWh)
/sys/class/power_supply/BAT0/charge_full                    =   5903 [mAh] ( 50801 mWh)
/sys/class/power_supply/BAT0/charge_now                     =   5144 [mAh] ( 44269 mWh)
/sys/class/power_supply/BAT0/current_now                    =   2689 [mA]  ( 23142 mW)
/sys/class/power_supply/BAT0/status                         = Charging

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

Charge                                                      =   87.1 [%]
Capacity                                                    =   88.8 [%]
Vielleicht wird deshalb die (obere) Ladeschwelle ignoriert?

Also [force-discharge] bleibt auch, wenn Charge > 90 [%] geht.
 
Unter Debian 12 gibt es keine Schaltflächen unter Gnome.
Kann ich bei mir nicht reproduzieren. Ist tlp-pd.service gestartet? Zeig mal bitte (ohne sudo):
Bash:
tlp-stat -s
tlp-stat --pd-diag

Puh: die jährliche Rekalibrierung durchgeführt! UPower ist ein Krampf...
@mcb UPower in Trixie ist naturgemäß zu alt. Config-Workaround siehe hier:
Mit der Lösung in UPower 1.91.1 ändert sich die Config dann nochmal.

Ich bin insgesamt froh, dass ich die Entwicklerin nach längerer Diskussion von meinem Ansatz überzeugen konnte:

/usr/sbin/tlp: 826: 1: not found
@iks230 Ist jetzt gelöst, neue Pakete sind hochgeladen. Bitte nochmal probieren.

Vielleicht wird deshalb die (obere) Ladeschwelle ignoriert?
Die Firmware will das halt so, wenn force-discharge aktiv ist. Works as designed 🤣.
 
Zuletzt bearbeitet:
Power in Trixie ist naturgemäß zu alt. Config-Workaround siehe hier:
Mit der Lösung in UPower 1.91.1 ändert sich die Config dann nochmal.
Ja, das ist hier bekannt.
Da ich nur sehr selten kalibriere ist das nicht so schlimm:
In der
/etc/UPower/UPower.conf
Code:
AllowRiskyCriticalPowerAction=false
## Rekalibrieren true sonst false -> shutdown
##AllowRiskyCriticalPowerAction=true
.....
# Rekalibrieren
CriticalPowerAction=Ignore
Muß ich ja nur 'AllowRiskyCriticalPowerAction' verstellen, soweit ich das überblicke.
Kann ich bei mir nicht reproduzieren. Ist tlp-pd.service gestartet? Zeig mal bitte (ohne sudo):
tlp-stat -s tlp-stat --pd-diag
Bekommst du spätestens Montag, ich komme da nicht immer dran.



Ist jetzt gelöst, neue Pakete sind hochgeladen. Bitte nochmal probieren.
Oh Arbeit.
@linrunner
Hier neue logs vom T14:
;)
 
Zuletzt bearbeitet:
@iks230 Ist jetzt gelöst, neue Pakete sind hochgeladen. Bitte nochmal probieren.
Funktioniert erstmal wie es soll, aber:

Szenario [1]: sudo tlp discharge -> Abbruch durch Netzteil ab -> Netzteil wieder dran -> obere Ladeschwelle wird gehalten

Szenario [2]: sudo tlp discharge -> mit Ctrl+C abgebrochen -> obere Ladeschwelle wird nicht gehalten

Szenario [2] wird nicht "geheilt" durch nur Netzteil ab/dran, sondern durch Szenario [1] (bzw. durch Neustart)

In beiden Szenarien steht charge_behaviour auf [auto] nach dem Abbruch (und während sudo tlp discharge auf [force-discharge]).
 
AllowRiskyCriticalPowerAction=false ## Rekalibrieren true sonst false -> shutdown ##AllowRiskyCriticalPowerAction=true ..... # Rekalibrieren CriticalPowerAction=IgnoreMuß ich ja nur 'AllowRiskyCriticalPowerAction' verstellen, soweit ich das überblicke.
Ich würde dennoch eher CriticalPowerAction=Ignore auskommentieren. Denn das schaltet Herunterfahren kurz bevor der Akku leer ist (2%) auch im Normalbetrieb ab. Es ist aber richtig, dass AllowRiskyCriticalPowerAction=true nötig ist, damit CriticalPowerAction=Ignore überhaupt aktiv wird. AllowRiskyCriticalPowerAction=true alleine bewirkt erstmal nichts, wird ab 1.91.1 dann für ExpectBatteryRecalibration=true benötigt.

@mcb EDITH sagt: in Sid gibt es upower 1.91.1 schon. Mal probiert ob sich das Paket händisch installieren lässt?

EDITH 2: jetzt auch "amtlich": https://linrunner.de/tlp/faq/battery.html#faq-discharge-shutdown

In beiden Szenarien steht charge_behaviour auf [auto] nach dem Abbruch (und während sudo tlp discharge auf [force-discharge]).
@iks230 Das wollte ich wissen. Dann funktioniert TLP jetzt komplett wie es soll.

obere Ladeschwelle wird gehalten
Darauf habe ich TLP-seitig keinerlei Einfluss, das verantwortet die EC-Firmware. Vielleicht ist es ja Absicht, dass sich das Chromebook am Ende des Entladens ausschaltet (wenn TLP nicht kurz vorher eingreifen würde und force-discharge zurücksetzen).

Falls Du einen anderen Workaround findest, können wir schauen, ob der in TLP aufgenommen werden kann. Ist aber bitte nicht Thema dieses Tests, das Problem muss auch schon mit 1.9.1 aufgetreten sein. Gab es zwischenzeitlich vielleicht ein Update der EC-Firmware?
 
Zuletzt bearbeitet:
  • ok1.de
  • thinkstore24.de
  • ok2.de - Notebook Computer Server
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben