Re: acpi_cmbat with charge-limited battery

On Mon, Mar 6, 2023 at 8:49 AM Rodney W. Grimes
<freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>
> > On Sun, Mar 5, 2023 at 9:33?PM Warner Losh <imp@bsdimp.com> wrote:
> > >
> > >
> > >
> > > On Sun, Mar 5, 2023 at 7:20?PM Kyle Evans <kevans@freebsd.org> wrote:
> > >>
> > >> Hello!
> > >>
> > >> I've dealt with this mainly over the weekend, but my solution was to
> > >> just disable acpi_cmbat entirely, which is maybe not the best solution
> > >> but I can't tell if this should be considered a firmware bug or if
> > >> it's something we could find a way to workaround in the kernel.
> > >>
> > >> Basically, I've set the firmware on my frame.work laptop to limit the
> > >> battery charge to 80%. When it hits 80% while plugged in, things get a
> > >> little funky- I assume it's because the firmware's trying to carefully
> > >> maintain the limit, but I end up getting (at least) one acpi
> > >> notification per second, alternating between BST_CHANGE/BIX_CHANGE,
> > >> which in turn drives up CPU usage as we tap it out to devd and upowerd
> > >> picks it up. upowerd ends up pegging a core consistently.
> > >>
> > >> Should we be rate-limiting these devd notifications? Is this even
> > >> reasonable behavior for the firmware? I'm not really sure how other OS
> > >> behave here, but I haven't really seen any complaints from other
> > >> framework'ers.
> > >
> > >
> > > Seems like this is crappy firmware behavior and we should rate
> > > limit in the driver... It's not useful information to be sharing once
> > > a second...
> > >
>
> I agree with that assesment of the firmware, but it brings up
> a question of is the firmware actually doing just what it is
> told?   I see above an upper limit on the charge has been
> set at 80%, but I do not see any mention of a "resume charging"
> after the battery drops to XX%.  I assume what is happening is
> the charge stops at 80%, we drop some load on the battery and
> it quickly drops to 79%, and the firmware decides it must
> start to charge again.
>
> Kyle, does the bios have settings for a resume charging?
> Also might be intereting to watch the battery level in
> a tight loop to see if you can catch the drop.
>

I haven't found any such setting, even after my last update to a BIOS
from ~a couple months ago. I tried `acpiconf -i0` in a tight loop and
captured the below transition. Interestingly, I wasn't able to capture
anywhere where it was charging and reported as < 80%, but for all I
know that's a rounding error and there's just not enough tolerance to
catch the difference.

Design capacity:    3572 mAh
Last full capacity: 3503 mAh
Technology:     secondary (rechargeable)
Design voltage:     15400 mV
Capacity (warn):    350 mAh
Capacity (low):     105 mAh
Cycle Count:        5
Measurement Accuracy:   0 %
Max Sampling Time:  0 ms
Min Sampling Time:  0 ms
Max Average Interval:   0 ms
Min Average Interval:   0 ms
Low/warn granularity:   264 mAh
Warn/full granularity:  3780 mAh
Model number:       Framewo
Serial number:      0260
Type:           LION
OEM info:       NVT
State:          discharging
Remaining capacity: 80%
Remaining time:     706:15
Present rate:       4 mA (66 mW)
Present voltage:    16594 mV

Design capacity:    3572 mAh
Last full capacity: 3503 mAh
Technology:     secondary (rechargeable)
Design voltage:     15400 mV
Capacity (warn):    350 mAh
Capacity (low):     105 mAh
Cycle Count:        5
Measurement Accuracy:   0 %
Max Sampling Time:  0 ms
Min Sampling Time:  0 ms
Max Average Interval:   0 ms
Min Average Interval:   0 ms
Low/warn granularity:   264 mAh
Warn/full granularity:  3780 mAh
Model number:       Framewo
Serial number:      0260
Type:           LION
OEM info:       NVT
State:          charging
Remaining capacity: 80%
Remaining time:     unknown
Present rate:       4 mA (66 mW)
Present voltage:    16600 mV