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
--000000000000ee54ad05f632f4fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 5, 2023 at 7:20=E2=80=AFPM Kyle Evans <kevans@freebsd.org> wrot= e: > 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 --000000000000ee54ad05f632f4fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 5, 2023 at 7:20=E2=80=AFP= M Kyle Evans <<a href=3D"mailto:kevans@freebsd.org">kevans@freebsd.org</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">He= llo!<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=3D"http://frame.work" re= l=3D"noreferrer" target=3D"_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 carefu= lly<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 c= rappy 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> --000000000000ee54ad05f632f4fe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp4JZCsuaQhbSuMYrYseu5n%2BHmASdEiCb0QM-2hr5Ja4g>