Stop threshold not working any more on LG Gram [Debian Sid, kernel 6.9.7]

[iacchi]

[x] I've read and accepted the Bug Reporting Howto [x] I've provided all required tlp-stat outputs via Gist (see below)

Describe the bug

I'm not quite sure if this is more of a TLP bug or a support request for something else in the system, but here I go. My laptop is running Debian Sid with kernel 6.9.7 and with secure boot enabled.

After a recent apt upgrade, I'm getting a message to disable secure boot to make third party drivers work in my system (I never had an issue so far for the year that I've had this laptop, and the dkms signing key is registered in the system so that drivers signed by dkms are accepted), which I'm refusing. More or less at the same time (not 100% sure), the battery charge limit to 80% stopped working. I used to set this threshold in KDE's system settings (which I think relies on TLP), but now my 80% value gets overridden to 50% in the KDE battery settings and ignored anyway as the battery gets charged to 100%. I've manually enabled the tlp service with systemctl and it's working correctly, however tlp-stat tells me that my system is not supported (but it was until a few days ago), here is the output of tlp-stat: https://pastecode.io/s/18fx72dk

If I try to manually edit /sys/devices/platform/lg-laptop/battery_care_limit with nano, I get this warning message in the text editor (as root of course):

[ Errore durante la scrittura del file di lock /sys/devices/platform/lg-laptop/.battery_care_limit.swp: Permesso negato ]

I'm sorry it's in Italian, it translates to something like: Error during writing lock file /sys/[...]: Permission denied.

If I try to input 80 and save the file, when I quit nano the value inside the file is still 0.

At this point I'm not quite sure if something has changed tlp-wise, kernel-wise, or what else. I'm happy to help debug to figure this out. I also have slimbook battery installed, I'm not sure if it's relevant or not.

[linrunner]

I used to set this threshold in KDE's system settings (which I think relies on TLP)

No, it doesn't. It directly writes to charge_control_end_threshold (see below).

I also have slimbook battery installed, I'm not sure if it's relevant or not.

The FAQ says

Slimbook Battery: uses TLP as a backend to apply power saving measures. However, it continuously overwrites your TLP configuration. If you wish to configure TLP individually, you must first uninstall Slimbook Battery.

Normally there would be no support for your constellation here.

However, I am interested in why the stop threshold cannot be written. For kernel 6.9 /sys/devices/platform/lg-laptop/battery_care_limit is no longer used for this but /sys/class/power_supply/BAT0/charge_control_end_threshold.

Please show the output of

grep . /sys/class/power_supply/BAT0/charge_control*

echo "80" | sudo tee /sys/class/power_supply/BAT0/charge_control_end_threshold

echo "80" | sudo tee /sys/devices/platform/lg-laptop/battery_care_limit

Btw: editing with nano is not suitable for changing sysfs nodes.

[iacchi]

Hello, and thank you for your reply. I turned off slimbook battery for the moment while we try to solve this. Also good to know that nano is not the way to go in this case - I didn't know that. Anyway, here's the output you asked for:

root@hactar:/usr/lib/modules# grep . /sys/class/power_supply/BAT0/charge_control*
0

root@hactar:/usr/lib/modules# echo "80" | tee /sys/class/power_supply/BAT0/charge_control_end_threshold
80
root@hactar:/usr/lib/modules# cat /sys/class/power_supply/BAT0/charge_control_end_threshold
0

root@hactar:/usr/lib/modules# echo "80" | tee /sys/devices/platform/lg-laptop/battery_care_limit
80
root@hactar:/usr/lib/modules# cat /sys/devices/platform/lg-laptop/battery_care_limit
0

It looks like the files are not being written... I've also tried to restart tlp.service and to input 80 in KDE's systemsettings, but both files are still at 0. Should I try to boot with kernel 6.8.12 (I still have it installed) to see if it goes back to working as usual? I understand that there was a change between the 6.8 and 6.9 kernel series?

[linrunner]

Of course. I assumed right from the start that this is a kernel issue. The commands were used to work that out. Whether and what has been changed? I have no idea.

The other possibility would be a recent BIOS update.

[iacchi]

It's definitely not a BIOS update, as there haven't been any for this laptop. I rebooted back to kernel 6.8.12 and now everything works again straight after reboot, without even needing to re-set the values:

root@hactar:/home/iacopo# cat /sys/devices/platform/lg-laptop/battery_care_limit
80
root@hactar:/home/iacopo# cat /sys/class/power_supply/BAT0/charge_control_end_threshold
80

So definitely there's something in kernel 6.9.7 that is messing this up. I'm unsure if I should continue debugging with you or if I should open a bug with Debian or with Linux directly?

[linrunner]

I'm unsure if I should continue debugging with you or if I should open a bug with Debian or with Linux directly?

There is nothing more to debug on the kernel level that I could help with. You may continue with a Debian bug report.

Just for the record, I would like to have the output of

sudo tlp-stat -s -b

with the 6.8 kernel.

[iacchi]

Ok then, I'll keep you posted (and link the Debian bug report) in case there's anything you need to know for the future! In the meantime, here's the output you asked for: https://pastecode.io/s/1mvfpyjk

[iacchi]

This is the bug opened with the Debian team, in case someone wants to follow it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076110

[tixwho]

Hi there! I'm on Arch with power-profiles-daemon using 2023 ver. LG Gram 17, and I have the same issue after a recent kernel update (can't tell which one exactly, but the most recent kernel Linux 6.9.9-arch-1-1 is not fixing it.) It seems like the issue is caused by a kernel problem independent of distributions. Should there be more testings needed I'll be happy to help!