Battery not found Fujitsu Lifebook s938

6

667i

Since 12-1-RELEASE where this worked perfectly, my FreeBSD cannot find the laptop's battery. A KDE widget displays -1 charge and shuts the system down as soon as the power cord detached

I don't believe this is a hardware issue as a Live Linux CD displays the battery correctly

Recently tried with 13.2 and 14.0 FreeBSD, same result

I would suspect a kernel module excluded from a list of loaded by default, but i'm out of ideas on how to verify that

Code: 
root@fujitsu:/home/iv # 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:        11922 mV

root@fujitsu:/home/iv # sysctl hw.acpi.battery
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

root@fujitsu:/home/iv # dmesg | grep -i acpi
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
ACPI APIC Table: <FUJ    PC      >
acpi0: <FUJ PC>
cpu0: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x22> port 0x62,0x66 on acpi0
acpi_button0: <Power Button> on acpi0
acpi_acad0: <AC Adapter> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
battery1: <ACPI Control Method Battery> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci3: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 16 at device 29.0 on pci0
pci4: <ACPI PCI bus> on pcib4
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
ACPI Warning: \134_SB.CMB1._BIX: Return Package is too small - found 20 elements, expected 21 (20201113/nsprepkg-799)
iicbus0: <Philips I2C bus (ACPI-hinted)> on ig4iic0
iicbus1: <Philips I2C bus (ACPI-hinted)> on ig4iic1
acpi_wmi0: <ACPI-WMI mapping> on acpi0
 
FreeBSD finds/detects two (control method) batteries.
Can you show the output of
acpiconf -i 1
acpidump -dt?
 
the 2nd battery is not physically present, sorry for not mentioning

root@fujitsu:/home/iv # 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

acpidump output attached
 

Attachments

  • acpidump.txt
    1.2 MB · Views: 69
Both batteries (only) support reporting battery information (_BIF, _BIX). FreeBSD probably thinks, both batteries are not present (aka not plugged in).

667i said:
hw.acpi.battery.state: 7
Click to expand...
I wonder what state 7 means.

You could run a verbose kernel..
There are only a handful of patches for battery related files since the release of 12.1 (= 31.01.2021). It should be possible to track it down. The files are in https://github.com/freebsd/freebsd-src/tree/main/sys/dev/acpica: acpi_cmbat.c, acpi_battery.c, acpivar.h, acpi.c.
Maybe open a bug report.
 
Just digging in a little bit deeper..

Code: 
#define ACPI_BATT_STAT_DISCHARG        0x0001
#define ACPI_BATT_STAT_CHARGING        0x0002
#define ACPI_BATT_STAT_CRITICAL        0x0004
#define ACPI_BATT_STAT_INVALID                    \
    (ACPI_BATT_STAT_DISCHARG | ACPI_BATT_STAT_CHARGING)
#define ACPI_BATT_STAT_BST_MASK                    \
    (ACPI_BATT_STAT_INVALID | ACPI_BATT_STAT_CRITICAL)
#define ACPI_BATT_STAT_NOT_PRESENT    ACPI_BATT_STAT_BST_MASK

So battery state 7 is part of a bitmask. For example, the battery may be reporting both charging and discharging, and be critically low. But since hw.battery.X is meant to be an abstraction layer for all the batteries combined, the value 7 is difficult to figure out. Not sure if hw.battery.state even makes sense in a multi-battery environment.
 
George said:
Just digging in a little bit deeper..

Code: 
#define ACPI_BATT_STAT_DISCHARG        0x0001
#define ACPI_BATT_STAT_CHARGING        0x0002
#define ACPI_BATT_STAT_CRITICAL        0x0004
#define ACPI_BATT_STAT_INVALID                    \
    (ACPI_BATT_STAT_DISCHARG | ACPI_BATT_STAT_CHARGING)
#define ACPI_BATT_STAT_BST_MASK                    \
    (ACPI_BATT_STAT_INVALID | ACPI_BATT_STAT_CRITICAL)
#define ACPI_BATT_STAT_NOT_PRESENT    ACPI_BATT_STAT_BST_MASK
Click to expand...

Close. That's from
/usr/src/sys/dev/acpica/acpiio.h where just above that is explained that charging and discharging bits can't both be on (state invalid) and plus critical bit is used for (synthetic) state 'not present'.

See /usr/src/usr.sbin/acpi/acpiconf.c for how these are displayed by acpiconf -i

George said:
So battery state 7 is part of a bitmask.
Click to expand...

It's the whole bitmask, and the comments describe it as 'not present'.

So neither battery is being detected. Battery1 is really not present, but battery0 is failing to be detected.

George said:
Not sure if hw.battery.state even makes sense in a multi-battery environment.
Click to expand...

acpiconf only ever reports on one, so that's ok. There's much more about multiple batteries in /usr/src/sys/dev/acpica/acpi_battery.c and perhaps acpidump tables and ASL.

None of which helps to discover why the primary battery is not detected, except a believable voltage.
 
667i said:
Since 12-1-RELEASE where this worked perfectly, my FreeBSD cannot find the laptop's battery. A KDE widget displays -1 charge and shuts the system down as soon as the power cord detached
Click to expand...

Shutting down could be KDE configuration; best do all battery tests outside KDE or X, especially for PRs.

So does it shut down if you boot into console mode?

[edit:] I guess not, from your commands given here. Does it die without power outside KDE? And will it boot into BIOS Setup on battery?

667i said:
I don't believe this is a hardware issue as a Live Linux CD displays the battery correctly

Recently tried with 13.2 and 14.0 FreeBSD, same result
Click to expand...

Ok. This is a non-removable battery, right? Is it possible to disconnect and reconnect it, or to measure its voltage with a meter?

667i said:
I would suspect a kernel module excluded from a list of loaded by default, but i'm out of ideas on how to verify that
Click to expand...

Are you loading acpi_fujitsu in /boot/loader.conf?

667i said:
Technology: primary (non-rechargeable)
Battery Swappable Capability: Non-swappable
Click to expand...

Non-rechargeable (?!?) Perhaps an artefact of the larger problem.

667i said:
Design voltage: 0 mV
Capacity (warn): 0 mWh
Capacity (low): 0 mWh
(...)
OEM info:
State: not present
Present voltage: 11922 mV
Click to expand...

Interesting it sees voltage.

667i said:
ACPI Warning: \134_SB.CMB1._BIX: Return Package is too small - found 20 elements, expected 21 (20201113/nsprepkg-799)
Click to expand...

Now THAT looks interesting.

System Board, Control Method Battery, extended battery info (perhaps)

November 2020 ACPICA; I wonder if that post-dates FreeBSD 12.1?

Like George suggested, this looks worthy of a PR; ACPI folks are very responsive in my experience.
 
George, smithi - first, thank you a lot for your comments

The battery is removable, i removed it and put back to eliminate a possible misalignment, no change in recognition. I would not have tools to check the voltage

KDE shutdown is a secondary problem - it's a power daemon, all these years i used to disable it and work with no battery state info, checking the red led for the critical level - i mentioned it in the first place only to bring some context
It does not shutdown in the console mode

I did not load acpi_fujitsu before; i added it to the loader.conf and it loaded at boot, listable in kldstat - no change with the battery

I run a live Linux once again and it finds and displays the battery info accurately:
live@darkstar:~$ acpi -V
Battery 0: Discharging, 36%, 01:53:45 remaining
Battery 0: design capacity 7100 mAh, last full capacity 6258 mAh = 88%

And:
live@darkstar:~$ acpi -V
Battery 0: Charging, 36%, 01:10:31 until charged
Battery 0: design capacity 7100 mAh, last full capacity 6258 mAh = 88%

The bug was reported to FreeBSD - the "regression" flag was added as the only activity and then happily forgotten, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252030

Now, the suggestion by George to track related patches sounds like the way to fix this - unfortunately this is beyond my current knowledge (never touched FreeBSD kernel). Frankly, i was hoping for a simple solution, thought it was unlikely they would drop support of relatively new hardware (my s936 was quite new at that time)
 
Linux driver has a function called "static int battery_bix_broken_package". We probably need something similar? Bix, according to the acpi specification, has 21 elements.

Code: 
if (use_bix && battery_bix_broken_package)
        result = extract_package(battery, buffer->pointer,
                extended_info_offsets + 1,
                ARRAY_SIZE(extended_info_offsets) - 1);
...
 
there are not huge diffs between 12.1 and 12.2 in acpi_battery.c. what ive seen at a quick look is that 12.2 uses bix structures and 12.1 uses bif. it looks fixable by a 'skilled amateur' with enough will
getting it commited is something else
 
covacat said:
there are not huge diffs between 12.1 and 12.2 in acpi_battery.c. what ive seen at a quick look is that 12.2 uses bix structures and 12.1 uses bif. it looks fixable by a 'skilled amateur' with enough will
getting it commited is something else
Click to expand...

Could be a good clue. I'm out of time for digging, but adding to the PR may help?
 
ok i tried

bringing the old 12.1's acpi_battery.c and then fixing compiling issues

without luck though. It compiled and installed, but now giving even less meaningful results:

root@fujitsu:/home/iv # acpiconf -i 0
acpiconf: get battery info (0) failed: Device not configured


Looks one needs to know what they're doing to even bring the old functionality back. Pity. Hope they will notice the bumped PR, otherwise i'll be Hello again Linux and systemd, can't say i really want to go that path
 
Thanks to the investigation done on this thread so far, I was able to dig in today and found the root cause. I documented it on the bug, along with a hack and suggestions for how to properly fix the problem [1]. The issue is that there are two revisions of _BIX (Battery Info Extended). Our Lifebooks claim to supply the later revision, but actually return the earlier, which the kernel barfs at. Linux doesn't have this problem as it only supports the earlier revision anyway.

The quirk for handling broken _BIX referenced in comment 9 above is a red herring by the way. It's the work aound for yet another case of invalid ACPI data that does not apply to our Lifebooks :).

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252030#c3
 
You must log in or register to reply here.
Back
Top