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

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