Re: acpi_cmbat with charge-limited battery

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

> 
> The more I think about it (and with your generally confirmatory
> response), the more I think approaching both problems independently is
> probably good. I added a quick sysctl to acpi_cmbat to allow an
> interval for folks with broken firmware like myself; I'll probably
> throw that up for review tomorrow-ish. I'll also reach out to
> frame.work folks and see if they can improve this in some way, but I
> suspect any action there will take a while.
> 
> Thanks,
> 
> Kyle Evans
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org