tpacpi-bat: Akkufunktionen für X220/T420 etc. – schon jemand Erfahrungen?

[fabio]

ok, werd ich versuchen, danke.

 

[fabio]

Hat leider auch nicht geklappt. Nach kurzem Entfernen des Akkus, einem Neustart lädt er nach Anschließen ans Netz munter weiter.

EDIT: Ich weiß zwar nicht wie ich abfragen kann, ob das Modul acpi_call geladen ist, sollte es aber sein, denn wenn ich nach dem Neustart die Ladeschwellen ändern will brauche ich es nicht mehr wie am Anfang mit modprobe neu laden.

EDIT2: ok, lsmod zeigt mir, dass es geladen ist.

 

[fabio]

Wollte nur mal berichten: das automatische Schreiben der Ladeschwellen hab ich leider noch nicht hinbekommen, aber solange man den Akku nicht entfernt funktioniert alles tadellos bis jetzt. Ich hab auch keine "Sprünge" erlebt bis jetzt, wie es nach kurzer Zeit immer passiert ist wenn ich die Ladeschwellen unter Windows gesetzt habe.

 

[fabio]

Also nochmal ein Update: weiterhin keine Probleme. Denke auch nicht, dass es noch welche geben wird. Falls doch werd ich berichten, ansonsten ist wohl davon auszugehen, dass alles tadellos funktioniert.

 

[X220 Ei]

Bei mir läuft das ganze jezt von automatisch. In /usr/lib/script/ ist das tpacpi-bat script.
Systemd files in /etc/systemd/system setzen die Ladeschwellen bei jedem boot.
Es gibt eine für Startwert und Endwert.
Die sehen so aus:
[Unit]
Description=Setzt Akku-Schwelle: Endwert
After=systemd-modules-load.service

[Service]
Type=oneshot
ExecStart=/usr/lib/script/tpacpi-bat stopChargeThreshold 1 88
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

systemctl-enable ... und fertig.

 

[fabio]

hm, systemd. Welche Distro hast du? Ich müsste mich vielleicht mal in upstart einarbeiten.

 

[linrunner]

Moin,

könnt ihr bestätigen, daß bei nicht gesetzten Schwellen (sprich: Akku zuvor entnommen oder noch jungfräulich)

tpacpi-bat startChargeThreshold 1
tpacpi-bat stopChargeThreshold 1

den Wert 0 liefern?

Auch läßt sich der Wert 100% nicht schreiben, d.h.

tpacpi-bat stopChargeThreshold 1 100

liefert

Call failure status returned: 0x80000000 at ./tpacpi-bat line 294.

Hingegen funktioniert

tpacpi-bat stopChargeThreshold 1 0

und ich hätte gerne meine Annahme (EDITH sagt: steht auch so in der Usage-Ausgabe des Skripts :facepalm bestätigt, dass dies "Werkseinstellung" bedeutet.

@fabio: Du musst doch nur richtig in rc.local eintragen. Zeig bitte

sudo -i which tpacpi-bat
cat /etc/rc.local

 

[fabio]

~$ sudo -i which tpacpi-bat
[sudo] password for fabio: 
/usr/local/sbin/tpacpi-bat

~$ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

tpacpi-bat startChargeThreshold 1 75
tpacpi-bat stopChargeThreshold 1 85

exit 0

 

[linrunner]

Füge mal das Laden des Kernelmoduls und absolute Pfade ein:

[B]modprobe acpi_call[/B]
[B]/usr/local/sbin/[/B]tpacpi-bat startChargeThreshold 1 75
[B]/usr/local/sbin/[/B]tpacpi-bat stopChargeThreshold 1 85

 

[fabio]

Soll acpi_call auch in /etc/modules bleiben oder von da wieder raus?
Ich muss auch acpi_call vorher nochmal kompilieren, so wie ich das verstanden habe, da es inzwischen schon ein Kernel-Update gab oder?

P.S.: scheint jetzt zu klappen. Ist jetzt aber zusätzlich die Frage, ob das acpi_call in der rc.local, die absolute Pfadangabe oder wirklich beides zusammen den gewünschten Erfolg gebracht hat. Vielleicht werd ich das per Ausschlussverfahren noch mal testen, wenn ich etwas mehr Zeit habe. Danke!

 

[linrunner]

Soll acpi_call auch in /etc/modules bleiben oder von da wieder raus??

Es stört nicht wenn es 2mal geladen wird.

Es gibt ein fertiges Paket mit eingebautem DKMS.

Zuvor muss jedoch das alte Modul weg. Schau mit

modinfo acpi_call

nach dem filename und lösche es dann.

 

[fabio]

Es gibt ein fertiges Paket mit eingebautem DKMS.

Aktualisiert sich das nach nem Kernel-Update selbst oder was macht das besser?

 

[linrunner]

Aktualisiert sich das nach nem Kernel-Update selbst

Exakt.

 

[fabio]

Ok, danke!

 

[fabio]

Hallo, hier auch nochmal ein Update: Seit gestern treten wieder Sprünge über mehr als 20% auf. Ich werd also das Modul und das Skript wieder entfernen und bloß die obere Ladeschwelle über tp-smapi setzen. Schade auch. Vielleicht liegt es doch an der Hardware? Da die Sprünge immer auftreten sobald beide Ladeschwellen gesetzt sind. Und gerade an der unteren scheint ja was geändert worden zu sein, da diese mit dem tp-smapi nicht gesetzt werden kann.

BTW. Kann ich unter Ubuntu irgendwie feststellen wieviele Ladezyklen mein Akku hinter sich hat?

EDIT: Ok, es steht wohl in der Datei cycle_count im Ordner /sys/devices/platform/smapi/BAT0, aber zählt smapi bei jeder Installation von neuem? Oder liest es den Wert irgendwie aus dem Akku selbst?

 

[linrunner]

Der Zyklen-Wert kommt natürlich aus dem Akku, welchen Sinn sollte er sonst überhaupt haben?

Hast Du mal rekalibriert per

tpacpi-bat forceDischarge 1 1

?

 

[fabio]

Keine Ahnung ich dachte vielleicht schreibt das Modul im schlimmsten Fall einfach nur wie oft auf- und entladen wurde.

Nein, rekalibriert habe ich nicht. Aber da es ganz genau das selbe Verhalten wie der Energie-Manager in Windows gezeigt hat, gehe ich mal davon aus, dass das auch nichts bringen würde.
Ich hab jetzt einmal - nachdem der Akku wegen des Sprungs gestern auf 4,4% abgefallen war nochmal solange aufgeladen, bis er wieder voll war. Das dauert nach solchen Sprüngen immer lange Zeit. Der Akku lädt dann immer erst ganz normal, bis da steht, dass er nur noch eine Minute zu laden hat, und dann braucht er immer noch ca. über eine Stunde bis er wirklich fertig ist. Danach funktioniert wieder alles.

Ich belass es jetzt auf jeden Fall bei ausschließlich der oberen Ladeschwell mit tp-smapi.