tlp probleem (recalibrate en discharge), op recente thinkpads na kernel upgrade enkele weken geleden

Beste medeforumleden,

Sinds ongeveer twee en een halve à drie weken, na kernel upgrade in Tumbleweed functioneert tlp niet meer volledig.

Het gaat om vrij recente hardware waar tlp (acpi-call en natacpi) tot de kernelupgrade goed functioneerde.

Inmiddels zijn er alweer diverse kernel upgrades geweest echter het euvel blijft.
Momenteel draaien mijn 4 ThinkPads allen kernel 5.13.4-1 default van 24 juni 2021

Volgens de tlp handleidng (linrunner.de) is natacpi actief
(citaat): "Starting with kernel 4.17 tpacpi-bat gets superseded by a new, native kernel API called natacpi (contained in the ubiquitious kernel module thinkpad_acpi). tlp-stat -b indicates this as follows:

+++ Battery Features
natacpi = active (data, thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi = inactive (ThinkPad not supported)

As of kernel 5.9 the patches for discharge/recalibrate haven’t been merged. A full implementation would look like this:

+++ Battery Features
natacpi = active (data, thresholds, recalibrate)
tpacpi-bat = inactive (superseded by natacpi)
tp-smapi = inactive (ThinkPad not supported)

With full natacpi support, you won’t need external kernel module packages anymore." (einde citaat)

Tot aan de kernel upgrade enkele weken geleden functioneerden data, tresholds en ook “recalibrate” prima.

Recalibrate (en ook forced discharge) functioneren nu niet langer en tlp-stat -b geeft de volgende output:

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = unknown status
tp-smapi   = inactive (ThinkPad not supported)

Deze output krijg ik op al mijn ThinkPads (X1, X1 Yoga, T460s en T480),
Ik hoop dat een van de mede forumleden hiermee bekend is en mij kan helpen met het weer activeren van recalibrate (en discharge)?

Het is geen halszaak de ThinkPads draaien verder uitstekend en zeer stabiel, een oplossing om recalibreren en geforceerde ontlading vande accu’s weer werkzaam te hebben zou, in het kader van accuonderhoud, wel heel fijn zijn.

Alvast dank voor jullie input.

Voor mijn Lenovo T550:

$ uname -r
5.13.4-1-default

$ sudo tlp-stat -b
--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = inactive (kernel module 'acpi_call' not installed)
tp-smapi   = inactive (ThinkPad not supported)

+++ ThinkPad Battery Status: BAT0
<allerlei stats>

+++ ThinkPad Battery Status: BAT1
<allerlei stats>

+++ Charge total                                            =   80.2 %]

+++ Recommendations
* Install acpi_call kernel module for ThinkPad battery recalibration

Op zoek naar acpi_call vond ik:

https://software.opensuse.org/package/acpi_call

Dus maar gedaan:

sudo zypper addrepo https://download.opensuse.org/repositories/Base:System/openSUSE_Tumbleweed/Base:System.repo
sudo zypper refresh
sudo zypper install acpi_call

Maar dat levert niet veel op, “sudo tlp-stat -b” geeft nu alleen exra berichten:

/usr/share/tlp/func.d/35-tlp-func-batt: line 25: 7526 Killed

Vraagje: Wat is de functionaliteit van tlp-stat die je mist?

@marel

Hi Marel,

Dank voor je antwoord, ben net terug en heb nu pas ingelogd en lees je antwoord, excuus voor de late reactie.

acpi_call heb ik al direct geïnstalleerd bij de installatie van Tumbleweed.

Voor mij is deze functie handig, omdat ik op kantoor en nu vooral thuis werkende vaak aan het snoer werk en dan heb ik de batterij 80-70% ingsteld dus blijft die op maximaal 80% en blijft de batterij vrij van de continue 100% spanning (wat de cellen op den duur sloopt). In mijn T460s zitten bijvoorbeeld 2 batterijen. 1 per week geef ik dan het volgende commando

tlp discharge BAT0

en een dag later

tlp discharge BAT1

Als die batterij dan leeg is laadt ik beide batterijen weer eenmalig naar 100% met

tlp fullcharge BAT0

en een dag later ook weer

tle fullcharge BAT1

Na de volle lading (100%) discharge ik de batterijen bieden to <70% en laat ze vervolgens weer een week tot 80% opgeladen als ik aan het snoer werk.

Verder geeft ik altijd

tlp fulcharge BAT0

&

tlp fullcharge BAT1

voor ik onderweg ga met mijn laptop of bij een cliënt werk en niet aan stroomnet zit.
Met een volle batterij op stap gaan is immers wel zo handig.

Door dit te doen zijn beide batterijen volgens Tunbleweed nog 95% (BAT0) en 94% (BAT1) gezond (de laptop is uit 2017 dus dit is erg mooi resultaat). Dit is dan na de 100% lading.

Dat werkte prima tot er zo’n 1,5-2 mnd een kernel update kwam.

Nu werkt discharge niet meer en calibrate ook niet, overigens calibrate gebruik ik niet of nauwelijks (op mijn T460s nog nooit gecalibreerd).

Met et oog op de hiervoor getoonde output denk dat het komt omdat “natacpi” (de nieuwe native kernel API) dat in de kernel is opgenomen niet (meer) volledig functioneel is, immers

tlp discharge BAT0x

werkt niet meer. Het is maar een gedachte …

Ik mis dus vooral de forced discharge functie van tlp. dat is waar het voor mij op neer komt.

Ik krijg nu dus dezelfde output die jij toont zie hieronder:

Race-Horse:~ # tlp discharge BAT0
/usr/share/tlp/func.d/35-tlp-func-batt: line 25: 11751 Killed                  $TPACPIBAT -g FD 1 > /dev/null 2>&1
Error: battery discharge/recalibrate not available.
Race-Horse:~ # tlp discharge BAT1
/usr/share/tlp/func.d/35-tlp-func-batt: line 25: 12075 Killed                  $TPACPIBAT -g FD 1 > /dev/null 2>&1
Error: battery discharge/recalibrate not available.

Weet jij iets om discharge en recalibrate hernieuwd aan het werk te krijgen?
Ik zou het prettig vinden als

tlp discharge BAT0

weer functioneert.

Dank voor je uitgebreide beschrijving van waarvoor je tlp gebruikt.

Dat het beter is voor batterijen om niet helemaal opgeladen te worden weet ik maar ik dacht dat dat ontladen (discharge) verleden tijd was uit de tijd van nickel-metal hydride (NiMH) batterijen. Alle beetje recente laptops hebben Lithium-Ion (Li-ion) batterijen en ik weet vrijwel zeker dat het daar niet helpt en zelfs slecht is.

Een aardige artikel met “te” veel informatie: https://batteryuniversity.com/article/bu-808-how-to-prolong-lithium-based-batteries

https://batteryuniversity.com/img/content/DST-cycles-web2.jpg

Bron: bovengenoemde website, het beste is ontladen van 75% lading naar 65% en dan weer opladen naar 75%, slechte van 100% lading naar 25%.

Tot nu toe eigenlijk niet bezig gehouden met batterij management en dat is geen slecht idee lees ik op https://linrunner.de/tlp/introduction.html

TLP’s default settings are already optimized for battery life, so you may just install and forget it.

Net als bijv. bij een Tesla is er al de nodige firmware/software die zelfstandig dingen optimaliseert.

Ik denk dat hier de oplossing is om minder te doen, hoewel dat misschien niet goed voelt :wink:

Hoewel ik niet echt behoefte iets met batterijmanagement te doen was ik wel benieuwd waar die foutmelding vandaan kwam.

/usr/share/tlp/func.d/35-tlp-func-batt: line 28: 4836 Killed $TPACPIBAT -g FD 1 > /dev/null 2>&1

Dus (als root) script geopend in de editor en zag dat je het probleem (als root) kan reproduceren met:

/usr/share/tlp/tpacpi-bat -g FD 1

Dat is een perl script en dat ken ik wel. Normaal kan je “perl -d” ervoor zetten dan dan komen er meer details naar buiten met de crash, maar nu nog steeds alleen maar “Killed”…

Na wat single steppen zie ik dat het fout gaat op:

**#** perl -d /usr/share/tlp/tpacpi-bat -v -g FD 1 
main::(/usr/share/tlp/tpacpi-bat:41): 
41:     my $acpiCallDev = '/proc/acpi/call'; 
  DB<1> c 433 
main::runAcpiCall(/usr/share/tlp/tpacpi-bat:433): 
433:      open FH, "> $acpiCallDev" or die "Cannot write to $acpiCallDev: $!"; 
  DB<2> p $acpiCallDev 
/proc/acpi/call
 DB<3> p "$aslBase.$call
" 
\_SB.PCI0.LPC.EC.HKEY.BDSG 0x1
DB<4> q
**#** [FONT=monospace]echo "\_SB.PCI0.LPC.EC.HKEY.BDSG 0x1" > /proc/acpi/call 
\_SB.PCI0.LPC.EC.HKEY.BDSG 0x1 
**#** cat /proc/acpi/call 
0x700lled[/FONT]

Dus het script wil gaan schrijven naar /proc/acpi/call en dat gaat fout, maar als ik dat (als root) probeer werkt het wel.

Zou het aan acpi_call liggen? Ik zit dat voor https://build.opensuse.org/package/show/Base:System/acpi_call de laatste wijziging is van een jaar geleden… (alleen snap ik niet waarom het package acpi_call*-kmp-default* heet),

Het lijkt me haast een probleem met perl…

Nog even verder geprobeerd maar het is inderdaad de combinatie van hoe perl iets naar /proc/acpi/call schrijft (open, write, close) en de proc_acpi driver die dit probleem triggert.

Mijn gevoel zegt dat het waarschijnlijk een probleem is met acpi_call dat wordt getriggerd met nieuwere kernel functionaliteit.

Waarom? https://github.com/mkottman/acpi_call/ lijkt sinds 2013 “dood” en ik zie dat er een fork is, https://github.com/nix-community/acpi_call, die wel actief is. Ik vermoed dat het met de nieuwe code van https://github.com/nix-community/acpi_call wel werkt, misschien probeer ik dat wel een keer.

Nog een ander debug idee:

Good old strace zegt:

**#** strace -f -o /tmp/acpi_call.trace perl -e "open FH, '>', '/proc/acpi/call'"
**#** cat /tmp/acpi_call.trace | tail

15646 openat(AT_FDCWD, "/proc/acpi/call", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
15646 ioctl(3, TCGETS, 0x7ffcf1036690)  = -1 ENOTTY (Inappropriate ioctl for device)
15646 lseek(3, 0, SEEK_CUR)             = ?
15646 +++ killed by SIGKILL +++

Dus waarschijnlijk op te lossen door perl/het script /proc/acpi/call anders te laten openen.

Issue gevonden:

Fix for 5.13+ kernels

En inderdaad als ik journalctl -b bekijk zie ik “Bug kernel NULL pointer dereference, adress: 0000000000000000”
Het enige wat ik nog niet snap is waarom het via de commando prompt wel werkt.

Voor de fix moet er dus een nieuwe versie komen van acpi_call.

Ik zie dat Arch linux over lijkt te zijn op nix-community / ** acpi_call, **zie issue #13, dat zou OpenSuse ook moeten doen.

Enorm bedankt voor het test-, uitzoek- en uitprobeerwerk!

Ik denk dat je de spijker op zijn kop slaat.

Ik ga dit allemaal nog eens laten bezinken.

Bedankt voor je inzichten en meedenken tot dusverre

Ik kom hier nog op terug.