Created attachment 220791 [details] output of acpidump -dt Right after upgrade to 12.2-RELEASE from 12.1-RELEASE battery reading was gone. As a consequence, KDE battery monitor started to display -1 and started to shutdown the system as soon as KDE was up It was perfectly working in 12.1-RELEASE root@fujitsu:/ # acpiconf -i 0 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Battery Swappable Capability: Non-swappable Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Cycle Count: 0 Mesurement 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: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: 12498 mV root@fujitsu:/ # acpiconf -i 1 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Cycle Count: 0 Mesurement 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: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown root@fujitsu:/ # sysctl hw.acpi hw.acpi.battery.info_expire: 5 hw.acpi.battery.units: 2 hw.acpi.battery.state: 7 hw.acpi.battery.rate: -1 hw.acpi.battery.time: -1 hw.acpi.battery.life: -1 hw.acpi.acline: 1 hw.acpi.cpu.cx_lowest: C1 hw.acpi.reset_video: 0 hw.acpi.handle_reboot: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 0 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.suspend_state: S3 hw.acpi.standby_state: NONE hw.acpi.lid_switch_state: S3 hw.acpi.sleep_button_state: S3 hw.acpi.power_button_state: S5 hw.acpi.supported_sleep_state: S3 S4 S5
This bug seems to have fallen between the cracks. It was submitted 4 days before Christmas and assigned to 'freebsd-acpi (Nobody)' (?) It has reemerged on the forums with some discussion at https://forums.freebsd.org/threads/battery-not-found-fujitsu-lifebook-s938.90026/ I hunted a bit and found this commit message re acpica 20201113: https://lists.freebsd.org/pipermail/svn-src-vendor/2020-November/005616.html While not spotting anything specific, I suspect this might be what differs between FreeBSD 12.1 and 12.3 ACPI. {Sh,C}ould I have added jkim@ to ccs?
Created attachment 245079 [details] Hack that makes battery status work on Fujitsu Lifebooks
The problem is that some Fujitsu Lifebooks return an invalid _BIX object. The first element of _BIX is a revision number, which indicates what elements will follow: * ACPI 4.0 defined _BIX revision 0 with 20 elements. * ACPI 6.0 introduced _BIX revision 1 with 21 elements. The problem is that the offending Lifebooks have the a non-zero _BIX revision, but provide 20 fields only. The ACPICA parser chokes on this [1], but that seems to be inconsequential. More importantly, our own battery info handling code also verifies that for revision > 0, there are at least 21 fields - and refuses to process the invalid _BIX. One workaround would be to introduce special case / quirk handling for Fujitsu Lifebooks. Another is to relax the requirements check: If there are only 20 elements, treat the _BIX as revision 0, no matter what revision number was provided by the device. I hacked my kernel to always treat _BIX as revision 0 and the battery status is working perfectly now on my Fujitsu Lifebook E5511 (see attached hack). Linux doesn't run into this problem by the way because it only supports the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the revision number or the 21st field added in ACPI 6.0. [1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815 [2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418
Created attachment 245108 [details] Patch fixing the bug
Here is a patch that actually fixes the bug. It makes the code more lenient so that it will treat a 20-element _BIX purporting to be revision 1 as a revision 0 _BIX instead.
(In reply to freebsd from comment #5) I'll land this with the author of Bartosz Fabianowski <freebsd@chillt.de> since that email is in the Contributors list already.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cd8c3af747cc300c8257c315c7576644e2bb86ff commit cd8c3af747cc300c8257c315c7576644e2bb86ff Author: Bartosz Fabianowski <freebsd@chillt.de> AuthorDate: 2024-10-02 18:21:28 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2024-10-02 18:30:15 +0000 ACPI: Treat all 20-element _BIX entires as revision 0 Some Fujitsu Lifebooks return an invalid _BIX object. The first element of _BIX is a revision number, which indicates what elements will follow: * ACPI 4.0 defined _BIX revision 0 with 20 elements. * ACPI 6.0 introduced _BIX revision 1 with 21 elements. The problem is that the offending Lifebooks have the a non-zero _BIX revision, but provide 20 fields only. The ACPICA parser chokes on this [1], but that seems to be inconsequential. More importantly, our own battery info handling code also verifies that for revision > 0, there are at least 21 fields - and refuses to process the invalid _BIX. One workaround would be to introduce special case / quirk handling for Fujitsu Lifebooks. A better one is to relax the requirements check: If there are only 20 elements, treat the _BIX as revision 0, no matter what revision number was provided by the device. Linux doesn't run into this problem by the way because it only supports the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the revision number or the 21st field added in ACPI 6.0. [1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815 [2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418 PR: 252030 Reviewed by: imp MFC After: 2 weeks sys/dev/acpica/acpi_cmbat.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
Warner can close this after MFCs.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4651f4be1ed36d72f6d299a040f9a41eeb5c43c4 commit 4651f4be1ed36d72f6d299a040f9a41eeb5c43c4 Author: Bartosz Fabianowski <freebsd@chillt.de> AuthorDate: 2024-10-02 18:21:28 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2024-12-07 00:01:59 +0000 ACPI: Treat all 20-element _BIX entires as revision 0 Some Fujitsu Lifebooks return an invalid _BIX object. The first element of _BIX is a revision number, which indicates what elements will follow: * ACPI 4.0 defined _BIX revision 0 with 20 elements. * ACPI 6.0 introduced _BIX revision 1 with 21 elements. The problem is that the offending Lifebooks have the a non-zero _BIX revision, but provide 20 fields only. The ACPICA parser chokes on this [1], but that seems to be inconsequential. More importantly, our own battery info handling code also verifies that for revision > 0, there are at least 21 fields - and refuses to process the invalid _BIX. One workaround would be to introduce special case / quirk handling for Fujitsu Lifebooks. A better one is to relax the requirements check: If there are only 20 elements, treat the _BIX as revision 0, no matter what revision number was provided by the device. Linux doesn't run into this problem by the way because it only supports the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the revision number or the 21st field added in ACPI 6.0. [1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815 [2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418 PR: 252030 Reviewed by: imp MFC After: 2 weeks (cherry picked from commit cd8c3af747cc300c8257c315c7576644e2bb86ff) sys/dev/acpica/acpi_cmbat.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3c59c4453f0efbb606da9bf6a879f53ae980a645 commit 3c59c4453f0efbb606da9bf6a879f53ae980a645 Author: Bartosz Fabianowski <freebsd@chillt.de> AuthorDate: 2024-10-02 18:21:28 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2024-12-07 00:11:27 +0000 ACPI: Treat all 20-element _BIX entires as revision 0 Some Fujitsu Lifebooks return an invalid _BIX object. The first element of _BIX is a revision number, which indicates what elements will follow: * ACPI 4.0 defined _BIX revision 0 with 20 elements. * ACPI 6.0 introduced _BIX revision 1 with 21 elements. The problem is that the offending Lifebooks have the a non-zero _BIX revision, but provide 20 fields only. The ACPICA parser chokes on this [1], but that seems to be inconsequential. More importantly, our own battery info handling code also verifies that for revision > 0, there are at least 21 fields - and refuses to process the invalid _BIX. One workaround would be to introduce special case / quirk handling for Fujitsu Lifebooks. A better one is to relax the requirements check: If there are only 20 elements, treat the _BIX as revision 0, no matter what revision number was provided by the device. Linux doesn't run into this problem by the way because it only supports the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the revision number or the 21st field added in ACPI 6.0. [1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815 [2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418 PR: 252030 Reviewed by: imp MFC After: 2 weeks (cherry picked from commit cd8c3af747cc300c8257c315c7576644e2bb86ff) sys/dev/acpica/acpi_cmbat.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
Doh! forgot MFC til now!