Date: Mon, 6 Mar 2023 09:28:49 +0530 From: MANAV KUMAR <manav1811kumar@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Kyle Evans <kevans@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: acpi_cmbat with charge-limited battery Message-ID: <CAEbvM6rqinJeKBGFtE97SojbWcquNBo1v7nx%2BZCUyS7%2BOGLc2g@mail.gmail.com> In-Reply-To: <CANCZdfp4JZCsuaQhbSuMYrYseu5n%2BHmASdEiCb0QM-2hr5Ja4g@mail.gmail.com> References: <CACNAnaG=vk0jnk4zhvmuW7cRTMFdCuiMJp7mBOMx_rKy7umuoQ@mail.gmail.com> <CANCZdfp4JZCsuaQhbSuMYrYseu5n%2BHmASdEiCb0QM-2hr5Ja4g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a754c405f63350f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pls Unsubscribe me from this emailing list. Thanks On Mon, 6 Mar 2023 at 09:03, Warner Losh <imp@bsdimp.com> wrote: > > > On Sun, Mar 5, 2023 at 7:20=E2=80=AFPM Kyle Evans <kevans@freebsd.org> wr= ote: > >> 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 > --000000000000a754c405f63350f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Pls Unsubscribe me from this emailing list.<div>Thanks</di= v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr= ">On Mon, 6 Mar 2023 at 09:03, Warner Losh <<a href=3D"mailto:imp@bsdimp= .com">imp@bsdimp.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 5, 20= 23 at 7:20=E2=80=AFPM Kyle Evans <<a href=3D"mailto:kevans@freebsd.org" = target=3D"_blank">kevans@freebsd.org</a>> wrote:<br></div><blockquote cl= ass=3D"gmail_quote" style=3D"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=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> </blockquote></div> --000000000000a754c405f63350f8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEbvM6rqinJeKBGFtE97SojbWcquNBo1v7nx%2BZCUyS7%2BOGLc2g>