https://bugzilla.kernel.org/show_bug.cgi?id=222159
Bug ID: 222159
Summary: ACPI: battery: probe fails with -14 on NEC PC-LZ550LS
(_BIX returns 19 elements, no Revision ID)
Product: ACPI
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Power-Battery
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 311199
--> https://bugzilla.kernel.org/attachment.cgi?id=311199&action=edit
dmesg before/after, DSDT excerpt, DMI, and both patches
The ACPI battery is never registered on this machine. The probe of the
acpi-battery driver fails with -14 because the firmware's _BIX method returns a
package with 19 elements while the driver's extraction expects the 20 described
by extended_info_offsets[]. The driver only falls back to _BIF when the
_evaluation_ of _BIX fails; here the evaluation succeeds (ACPICA only warns),
the
extraction fails, and the probe aborts.
This is the same defect reported for the sibling model NEC PC-LZ750LS in
bug 67351 ("ACPI Fix that breaks _BIX table parsing."), which was closed with
CODE_FIX after adding the DMI quirk battery_bix_broken_package_quirk for that
model. The _BIX package on this machine is byte-identical in the relevant part
(Name (BIX0, Package (0x13) { One, 0x1130, 0x1130, One, 0x39D0, Zero, Zero, ...
} ), so the same fix applies: the model is simply not in the DMI table.
Requested in the 2013 report: DMI identification (attached), which for this
machine is NEC / PC-LZ550LS / board MS-1391 / BIOS /738A0600 12/04/2012.
Environment
-----------
Kernel: 7.0.0-38-generic (Ubuntu 26.04, 7.0.14), ACPICA 20251212
Machine: NEC PC-LZ550LS (board MS-1391), BIOS /738A0600 12/04/2012
Device: \_SB.PCI0.LPCB.EC.BAT1, PNP0C0A:00, _STA = 0x1F (battery present)
Symptom
-------
$ ls /sys/class/power_supply/
ADP1 # AC adapter only, no BAT1
upower: percentage 0%, icon "battery-missing-symbolic"
Consequences: no percentage, no energy/full/design values (battery health
cannot
be measured), and logind/upower cannot act on a critical battery level, so the
machine powers off abruptly when the battery is exhausted.
Evidence
--------
ACPI Warning: \_SB.PCI0.LPCB.EC.BAT1._BIX: Return Package is too small -
found 19 elements, expected 21 (20251212/nsprepkg-649)
acpi-battery PNP0C0A:00: probe with driver acpi-battery failed with error -14
Firmware analysis (acpidump -b, iasl -d; excerpt attached)
----------------------------------------------------------
_BIX returns BIX0, a Package (0x13) = 19 elements, filled at run time by UPBX()
from the EC. As diagnosed in bug 67351, the package does not have the Revision
ID in the first position: element [0] is the Power Unit (1 = mA). The rest
follows the _BIF-like layout (design capacity at [1], last full charge at [2],
design voltage at [4], warning/low at [5]/[6]), the strings are at [15..18],
and
there is no OEM Information element. This is exactly what
battery_bix_broken_package_quirk is for.
Proposed fix
------------
Add the model to the DMI table (6 lines, same pattern as the LZ750 entry):
{
/* NEC LZ550/LS */
.callback = battery_bix_broken_package_quirk,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
DMI_MATCH(DMI_PRODUCT_NAME, "PC-LZ550LS"),
},
},
Patch attached (0001-acpi-battery-add-nec-lz550ls-quirk.patch).
Verification
------------
The machine runs a distribution kernel, so the change was validated by building
drivers/acpi/battery.c as an out-of-tree module with
battery_bix_broken_package = 1 (which is what the DMI match sets), i.e. the
same
code path the patch enables:
ACPI: battery: Slot [BAT1] (battery present) [no "_BIX is broken"
warning]
status Full
capacity 100
charge_now 1404000 uAh
charge_full 1404000 uAh
charge_full_design 3000000 uAh
voltage_now 12.197 V
cycle_count 80
model_name PC-VP-BP86/OP-570-77009
manufacturer NEC
The resulting values are consistent, and cycle_count (80) is plausible for a
2012 battery, which corroborates that the quirk's element mapping is correct
(without the quirk, the probe fails and the partial _BIX parse leaves
cycle_count = 80000).
Alternative considered
----------------------
A generic fix is also possible: let acpi_battery_get_info() continue the loop
when extract_battery_info() fails, so the standard _BIF path (present and
13-element compliant on this machine) is used:
- break;
+ if (!result)
+ break;
This was verified as well (attached as an alternative patch) and would help any
firmware with a short or unparsable _BIX, at the cost of masking firmware bugs
instead of quirk-ing them. Mentioned here for completeness; the DMI quirk
matches the precedent from bug 67351.
What I could not do
-------------------
- Test the patch against the built-in driver: only an out-of-tree module build
was possible on this machine.
- Test on other hardware.
- The patches are attached as proposals; nothing has been submitted to
linux-acpi.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
