From nobody Tue Mar 07 03:57:04 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PW1qJ0Fl3z3wqBF for ; Tue, 7 Mar 2023 03:57:16 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PW1qH6x3Cz43cL; Tue, 7 Mar 2023 03:57:15 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678161436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qDaeAOeNR//gjvTPyOLmDcWJsXuRax7uM9P4m/vugTs=; b=ynObWNmQuxm/0LFchaon1+c6leohMVxMqy774FB9uOLJe7ndX3pk9qRa5Z2lP3LwVFHB/n ZO0fMRccs2jWS06LqUO+p/GR2apghfa4HKtFOWPCo5tfAiGXGwBytf4cRwIz+vRin8xD9e FIZR0r/306j7JCjVHaXcb3foUNfxyPoSLjuMXVCEAXzNIEiW4u1k/JHBmxaVWktoKTr1Ai vJXkLoYrprebQzxz/1VMsr/Bo7Kk3Ljn+wNNq/vkKyFuo2o/SrDxwOoqnzvYN5Y2jgaat1 KbhhS26fdapvtWL7N6byF4ce1kiIvwS7cF7vY/8tKH8gmo6UBSigpfQcWIavkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678161436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qDaeAOeNR//gjvTPyOLmDcWJsXuRax7uM9P4m/vugTs=; b=v7pb8MlqubQ8PRwj3NiHm19iyPHSDytcyN7/fwWbY//v8UfRL+XiYBo6bS60Sq1KNai39r duOZV39QBz7NFZtw56I3JVwq74DNP+yxSH5sQqcp/E3QStylOtScvXlLjutTus5Md32f/N 6Sg1a0r88l+GzdU1fSEPcnXT58zsiLgpz8YuaH14k8d1piwC6tWGqcmdXWvcdVS2MM4H0Q 9l41QKFKFP15hdnjH/3I9gWimZfNak1Zb/MMbmOAo7Zi6k0vWScOFqSXNiKhVtMCnEmV2e lz6zgMpL/PEQiNZaqrJX7f4180Pi2XqnHtTv9WsMe5In20Pl0O4o1cv/GKzLPw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1678161436; a=rsa-sha256; cv=none; b=gGgXJ114OvB6n4OvpVHj56MA1bx/GaZt79IBZ/hJvDy3RRSlzuf+Ay6VBNASEj9RnKH3Ud 7GcUJANIz8UbND7sLva4ZokByWU0dlRXiNm2BtvBA4SYnBfroeNXPcgECpe9c2vXb4SRcM tlouJ989sRJHEZyz3PRt7ULF4Jakk2im2LBLsVM2uQ2G95PHCmz+l38pq5A0zNrMPBog75 vToN/tYRlpaPzXjSYFEJfQ6y0Om3RQW/NCV4WQteH3RgF/+iN2Y4mGfaXK6F2eFlzIOmxK n5TwxKgW7uWS1/ZDX6Ynyv29X/YFeUfPoGQ2cS6oYpyvI/mgwa8uMiP2/KuJIA== Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PW1qH5pnpzLg2; Tue, 7 Mar 2023 03:57:15 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f54.google.com with SMTP id g9so6475498qvt.8; Mon, 06 Mar 2023 19:57:15 -0800 (PST) X-Gm-Message-State: AO0yUKVFlEbISvWXUAun45dkxejYTXah2YgFi8fICIrFeC5saAIXgYJm aRTAqpXCVTV3uTQxpOIvuU94EoKTRdEYLU2Vw2g= X-Google-Smtp-Source: AK7set+HCcB2ERDANS6x5jFda0ZjqGNEfmRLTPU1mB6Nbu5lqg+NiZsBSBJQsPURLT9sAwHk2+ZJTg+sCs8hHNUT7kA= X-Received: by 2002:a05:6214:1752:b0:56c:1865:feb with SMTP id dc18-20020a056214175200b0056c18650febmr3867550qvb.3.1678161435455; Mon, 06 Mar 2023 19:57:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202303061449.326EnUrV078466@gndrsh.dnsmgr.net> In-Reply-To: <202303061449.326EnUrV078466@gndrsh.dnsmgr.net> From: Kyle Evans Date: Mon, 6 Mar 2023 21:57:04 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: acpi_cmbat with charge-limited battery To: "Rodney W. Grimes" Cc: Kyle Evans , Warner Losh , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 6, 2023 at 8:49=E2=80=AFAM Rodney W. Grimes wrote: > > > On Sun, Mar 5, 2023 at 9:33?PM Warner Losh wrote: > > > > > > > > > > > > On Sun, Mar 5, 2023 at 7:20?PM Kyle Evans 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 soluti= on > > >> 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 th= e > > >> 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 careful= ly > > >> 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 upowe= rd > > >> 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. > I haven't found any such setting, even after my last update to a BIOS from ~a couple months ago. I tried `acpiconf -i0` in a tight loop and captured the below transition. Interestingly, I wasn't able to capture anywhere where it was charging and reported as < 80%, but for all I know that's a rounding error and there's just not enough tolerance to catch the difference. Design capacity: 3572 mAh Last full capacity: 3503 mAh Technology: secondary (rechargeable) Design voltage: 15400 mV Capacity (warn): 350 mAh Capacity (low): 105 mAh Cycle Count: 5 Measurement Accuracy: 0 % Max Sampling Time: 0 ms Min Sampling Time: 0 ms Max Average Interval: 0 ms Min Average Interval: 0 ms Low/warn granularity: 264 mAh Warn/full granularity: 3780 mAh Model number: Framewo Serial number: 0260 Type: LION OEM info: NVT State: discharging Remaining capacity: 80% Remaining time: 706:15 Present rate: 4 mA (66 mW) Present voltage: 16594 mV Design capacity: 3572 mAh Last full capacity: 3503 mAh Technology: secondary (rechargeable) Design voltage: 15400 mV Capacity (warn): 350 mAh Capacity (low): 105 mAh Cycle Count: 5 Measurement Accuracy: 0 % Max Sampling Time: 0 ms Min Sampling Time: 0 ms Max Average Interval: 0 ms Min Average Interval: 0 ms Low/warn granularity: 264 mAh Warn/full granularity: 3780 mAh Model number: Framewo Serial number: 0260 Type: LION OEM info: NVT State: charging Remaining capacity: 80% Remaining time: unknown Present rate: 4 mA (66 mW) Present voltage: 16600 mV