Date: Sun, 5 Mar 2023 20:33:14 -0700 From: Warner Losh <imp@bsdimp.com> To: Kyle Evans <kevans@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: acpi_cmbat with charge-limited battery Message-ID: <CANCZdfp4JZCsuaQhbSuMYrYseu5n%2BHmASdEiCb0QM-2hr5Ja4g@mail.gmail.com> In-Reply-To: <CACNAnaG=vk0jnk4zhvmuW7cRTMFdCuiMJp7mBOMx_rKy7umuoQ@mail.gmail.com> References: <CACNAnaG=vk0jnk4zhvmuW7cRTMFdCuiMJp7mBOMx_rKy7umuoQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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... Warner [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 5, 2023 at 7:20 PM Kyle Evans <<a href="mailto:kevans@freebsd.org">kevans@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br> <br> I've dealt with this mainly over the weekend, but my solution was to<br> just disable acpi_cmbat entirely, which is maybe not the best solution<br> but I can't tell if this should be considered a firmware bug or if<br> it's something we could find a way to workaround in the kernel.<br> <br> Basically, I've set the firmware on my <a href="http://frame.work" rel="noreferrer" target="_blank">frame.work</a> laptop to limit the<br> battery charge to 80%. When it hits 80% while plugged in, things get a<br> little funky- I assume it's because the firmware's trying to carefully<br> maintain the limit, but I end up getting (at least) one acpi<br> notification per second, alternating between BST_CHANGE/BIX_CHANGE,<br> which in turn drives up CPU usage as we tap it out to devd and upowerd<br> picks it up. upowerd ends up pegging a core consistently.<br> <br> Should we be rate-limiting these devd notifications? Is this even<br> reasonable behavior for the firmware? I'm not really sure how other OS<br> behave here, but I haven't really seen any complaints from other<br> framework'ers.<br></blockquote><div><br></div><div>Seems like this is crappy firmware behavior and we should rate</div><div>limit in the driver... It's not useful information to be sharing once</div><div>a second...</div><div><br></div><div>Warner<br></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp4JZCsuaQhbSuMYrYseu5n%2BHmASdEiCb0QM-2hr5Ja4g>