Works great on Acer Swift Edge 16 SFA16-41

[sos-michael]

Fedora 37 + Custom Kernel : 6.2.0-cbl5.0.fc37.x86_64

Used insmod acer-wmi-battery.ko enable_health_mode=1, stopped charging immediately @ 92%

Thanks!

[Smegheid]

Ubuntu 22.04, stock kernel (currently 5.19.0-32-generic #33~22.04.1-Ubuntu).

tlp-stat -b still shows the generic battery care plugin and no threshold changes are possible, but in a quick test of loading the module @ 84%, Ubuntu's power settings reports the battery is not charging and is holding steady at that level.

Costco's sale price of $900 is looking better and better...

[sos-michael]

@Smegheid This is 100% not related to the wmi battery kernel module, but could I ask a quick favor?

Run geekbench 6 while on battery? Let me know if you can finish the run or if the system powers off at some point during the multicore test?

I can't decide if I have hardware fault in the battery circuitry or if some PM thing is configured incorrectly... Only happens under linux while battery powered.

[maniacx]

Just curious Does the battery health mode work with sysfs command? i.e. Setting health mode using echo and reading back with cat. echo 1 | sudo tee /sys/bus/wmi/drivers/acer-wmi-battery/health_mode to read back the settings cat sudo tee /sys/bus/wmi/drivers/acer-wmi-battery/health_mode

I made a gnome extension Battery Health Charging to control charging threshold for some supported laptop. And it depends on setting and reading through sysfs.

But after seeing most of issues, of not being able to control via sysfs but can control using insmod acer-wmi-battery.ko enable_health_mode=1 thinking may be I should drop support. @Smegheid , @sos-michael can anyone confirm?

[sos-michael]

@maniacx: Unfortunately, I don't think so.

[root@parisi ~]# cat /sys/bus/wmi/drivers/acer-wmi-battery/health_mode

1

[root@parisi ~]# echo 0 | tee /sys/bus/wmi/drivers/acer-wmi-battery/health_mode

0

[root@parisi ~]# cat /sys/bus/wmi/drivers/acer-wmi-battery/health_mode

1

[root@parisi ~]# cat tee /sys/bus/wmi/drivers/acer-wmi-battery/health_mode

cat: tee: No such file or directory

1

[maniacx]

According to this post it seems like the health_mode does get applied but doesn't show when read with 'cat'.

Could you try enabling and disabling the calibration mode and see if calibration mode changes using sysfs?

echo "1" | sudo tee /sys/bus/wmi/drivers/acer-wmi-battery/calibration_mode then cat /sys/bus/wmi/drivers/acer-wmi-battery/calibration_mode

if cat reads 1 then disable calibration mode again

echo "0" | sudo tee /sys/bus/wmi/drivers/acer-wmi-battery/calibration_mode and check again

cat /sys/bus/wmi/drivers/acer-wmi-battery/calibration_mode check if it reads 0

Let me know if this works.

[maniacx]

If calibration mode works using sysfs, I think this might be the solution to the problem for health mode to show correctly in sysfs. https://github.com/maniacx/acer-wmi-battery/commit/4747abd90d1e8135a87302bd91177ab2431eec89 But i am not sure though.

[maniacx]

FYI asant confirms the patch works, and so does the extension https://github.com/frederik-h/acer-wmi-battery/issues/14#issuecomment-1465355110

Thank you for your help

[Smegheid]

@sos-michael: no problems here completing multi-core geekbench on battery. The full test runs to completion with no weirdnesses on my machine.

Vanilla Ubuntu 22.04, connected to an external 3440x1400 screen via a little USB-C dock with the power input disconnected, power limits set to their defaults for the duration of the test.

[sos-michael]

@Smegheid Very interesting.

I see some weird interplay between the governor and the power limit. If I use schedutil it never crashes, but my geekbench6 numbers on battery drop across the board and almost halve for MC (5100). The power limit doesn't matter, this even happens when I run at the undocumented max battery power limit (29.5W/32.3W).

However if I use conservative values (something like 20/30) with the (default on fedora) performance gov, it will just crash. My guess was either faulty circuitry or the CPU just pulls too much current too quickly when the system jumps for idle to the max short power limit while using AVX instructions. There appears to be an overshoot when AVX instructions get called. Even with the max set to 30, I'll briefly see values closer to 35).

Anyway, thanks for running the test!