Date: Mon, 6 Mar 2023 06:49:30 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Kyle Evans <kevans@FreeBSD.org> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <freebsd-hackers@FreeBSD.org> Subject: Re: acpi_cmbat with charge-limited battery Message-ID: <202303061449.326EnUrV078466@gndrsh.dnsmgr.net> In-Reply-To: <CACNAnaHHUoxBpoyynUXtLWnghLTV9S5CNjSiURb%2BDiJDF7WjFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202303061449.326EnUrV078466>