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.

The fact that your able to capture it as both charging and discharging
at an 80% full capacity leads me to believe the firmware has no
hysterisis around this battery full setting and is infact flipping
the charger on and off every second in an attempt to keep the battery
at that 80% level.

A comment inline with the battery reports below.


> 
> 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
Wow, that is a 7% step size.
I am more use to seeing this as some double digit value near 1/100
of "Design Capacity".  For this battery I would expect to be seeing
35mAh or so.

> Warn/full granularity:  3780 mAh
Wait a minute, how can this granularity be larger than the total battery size?
I am use to seeing this value as the same as Low/warn granularity.

> 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)

This number also seems bonkers, there is no way no laptop
running FreeBSD is doing so on 66mW of power!!!!  That wouldnt
even power up an LED backlight of any reasonable brightness.

Perhaps get a new set of "Discharging" values with the
AC adapter un plugged and the battery discharging for
at least a minute.

> 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)

Again this nuber looks bonkers, charging at this power
level makes no since at all.  
> Present voltage:    16600 mV
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org