battery not recognized in Fujitsu Lifebook

English Install/Boot/Login
1

I have just installed Leap 15.3 on a Fujitsi Lifebook A3510 (KDE). BIOS is version 1.10 dated 04/23/2021. I am not aware of a more recent one.
Unfortunately, I find a problem with power management.
Symptoms:
(1) The system tray icon “battery and brightness” does not show the battery status, but rather tells me that no battery is available (of course there is one).
(2) The KDE Info Center does not show any energy information.
(3) In System Settings->Power Management there is only a single page, not three tabs (On AC Power, On Battery, On Low Battery) as I see on other Leap 15.3 installations (other Fujitsu Lifebooks) that I have available here.

I have made a couple of test:
(1) checking kernel messages with dmesg gives

> sudo dmesg -T | grep -i battery
[So Sep 12 11:36:57 2021] battery: ACPI: Battery Slot [BAT1] (battery absent)

I get this message regardless of booting the notebook with the AC adapter connected to the power line or not. I have tried a recommendation found in the internet that suggests to boot the machine once with AC connected and the battery removed, then reinsert the battery and boot - but no change.

Other discussions seem to deal with outdated BIOS’es, except maybe the recommendation to boot with acpi=off[FONT=arial], which makes booting to fail,[FONT=courier new] acpi=ht, which allows boot, but does not bring upon a change for the problem or pci=noapi, which also prvents booting. [/FONT][/FONT]

(2) the acpi -a command results in

> acpi -a
Adapter 0: off-line

if the machine is booted with AC not connected, and

> acpi -a
Adapter 0: on-line

if it is booted with AC connected. Once booted, this command’s result does not change if the AC adapter is connected or removed while running the system.
So, it seems that the status of the AC adapter during boot is recognized but never updated later.

(3) acpi -V gives

> acpi -V
Adapter 0: on-line
Thermal 0: ok, 50.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 99.0 degrees C
Cooling 0: Processor 0 of 10
Cooling 1: Processor 0 of 10
Cooling 2: x86_pkg_temp no state information available
Cooling 3: Processor 0 of 10
Cooling 4: intel_powerclamp no state information available
Cooling 5: Processor 0 of 10
Cooling 6: iwlwifi_1 no state information available

again there is no response in the running system when inserting or removing the AC adapter.
This is even true if the acpid daemon is restarted. In no case, there appears a battery entry.

(4) upower:

> sudo upower -d
[sudo] Passwort für root:
Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:          ACAD
  power supply:         yes
  updated:              So 12 Sep 2021 11:09:43 CEST (46 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    warning-level:       none
    online:              no
    icon-name:          'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              So 12 Sep 2021 11:09:43 CEST (46 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    icon-name:          'battery-missing-symbolic'

Daemon:
  daemon-version:  0.99.11
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: Hibernate

Again, as for acpi, the status of the adapter at boot time is recognized (here online: no), but not changed later, not even if upower is restarted with systemctl. Note, there is no entry for a battery.

(5) dmidecode (I deleted some information to keep the message size within limits …):

> sudo dmidecode
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Table at 0x3CFBD000.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
    Vendor: FUJITSU CLIENT COMPUTING LIMITED
    Version: Version 1.10
    Release Date: 04/23/2021
    Address: 0xE0000
    Runtime Size: 128 kB
    ROM Size: 12288 kB
    Characteristics:
        PCI is supported
        BIOS is upgradeable
        BIOS shadowing is allowed
        Boot from CD is supported
        Selectable boot is supported
        ACPI is supported
        USB legacy is supported
        Function key-initiated network boot is supported
        Targeted content distribution is supported
        UEFI is supported
    BIOS Revision: 1.10
    Firmware Revision: 1.8

Handle 0x0001, DMI type 1, 27 bytes
System Information
    Manufacturer: FUJITSU CLIENT COMPUTING LIMITED
    Product Name: LIFEBOOK A3510
    Version:  
    Serial Number: EQAB157129
    UUID: 169230cd-e4d8-eb11-8b14-b0912bde2370
    Wake-up Type: Power Switch
    SKU Number: SK00
    Family: LIFEBOOK-FTS

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
    Manufacturer: FUJITSU CLIENT COMPUTING LIMITED
    Product Name: FJNBB6D
    Version: EQAB157129
    Serial Number: EQAB157129
    Asset Tag:  
    Features:
        Board is a hosting board
    Location In Chassis:  
    Chassis Handle: 0x0003
    Type: Motherboard
    Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
    Manufacturer: FUJITSU CLIENT COMPUTING LIMITED
    Type: Notebook
    Lock: Not Present
    Version:  
    Serial Number: EQAB157129
    Asset Tag:  
    Boot-up State: Unknown
    Power Supply State: Unknown
    Thermal State: Unknown
    Security Status: Unknown
    OEM Information: 0x00000000
    Height: Unspecified
    Number Of Power Cords: Unspecified
    Contained Elements: 0
    SKU Number:  

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
    Socket Designation: Onboard
    Type: Central Processor
    Family: Core i3
    Manufacturer: Intel(R) Corporation
    ID: E5 06 07 00 FF FB EB BF
    Signature: Type 0, Family 6, Model 126, Stepping 5
    Flags:
        FPU (Floating-point unit on-chip)
        VME (Virtual mode extension)
        DE (Debugging extension)
        PSE (Page size extension)
        TSC (Time stamp counter)
        MSR (Model specific registers)
        PAE (Physical address extension)
        MCE (Machine check exception)
        CX8 (CMPXCHG8 instruction supported)
        APIC (On-chip APIC hardware supported)
        SEP (Fast system call)
        MTRR (Memory type range registers)
        PGE (Page global enable)
        MCA (Machine check architecture)
        CMOV (Conditional move instruction supported)
        PAT (Page attribute table)
        PSE-36 (36-bit page size extension)
        CLFSH (CLFLUSH instruction supported)
        DS (Debug store)
        ACPI (ACPI supported)
        MMX (MMX technology supported)
        FXSR (FXSAVE and FXSTOR instructions supported)
        SSE (Streaming SIMD extensions)
        SSE2 (Streaming SIMD extensions 2)
        SS (Self-snoop)
        HTT (Multi-threading)
        TM (Thermal monitor supported)
        PBE (Pending break enabled)
    Version: Intel(R) Core(TM) i3-1005G1 CPU @ 1.20GHz
    Voltage: 0.6 V
    External Clock: 100 MHz
    Max Speed: 8300 MHz
    Current Speed: 1100 MHz
    Status: Populated, Enabled
    Upgrade: Other
    L1 Cache Handle: 0x0006
    L2 Cache Handle: 0x0007
    L3 Cache Handle: 0x0008
    Serial Number:  
    Asset Tag:  
    Part Number:  
    Core Count: 2
    Core Enabled: 2
    Thread Count: 4
    Characteristics:
        64-bit capable
        Multi-Core
        Hardware Thread
        Execute Protection
        Enhanced Virtualization
        Power/Performance Control

...

Handle 0x000D, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 32 GB
    Error Information Handle: Not Provided
    Number Of Devices: 2

Handle 0x000E, DMI type 17, 84 bytes
Memory Device
    Array Handle: 0x000D
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: SODIMM
    Set: None
    Locator: ChannelA-DIMM0
    Bank Locator: BANK 0
    Type: DDR4
    Type Detail: Synchronous
    Speed: 3200 MT/s
    Manufacturer: Micron
    Serial Number: 2E8B23AA
    Asset Tag: 9876543210
    Part Number: 4ATF1G64HZ-3G2E1    
    Rank: 1
    Configured Memory Speed: 3200 MT/s
    Minimum Voltage: 1.35 V
    Maximum Voltage: 1.35 V
    Configured Voltage: 1.2 V
    Memory Technology: DRAM
    Memory Operating Mode Capability: Volatile memory
    Firmware Version: Not Specified
    Module Manufacturer ID: Bank 1, Hex 0x2C
    Module Product ID: Unknown
    Memory Subsystem Controller Manufacturer ID: Unknown
    Memory Subsystem Controller Product ID: Unknown
    Non-Volatile Size: None
    Volatile Size: 8 GB
    Cache Size: None
    Logical Size: None

Handle 0x000F, DMI type 17, 84 bytes
Memory Device
    Array Handle: 0x000D
    Error Information Handle: Not Provided
    Total Width: Unknown
    Data Width: Unknown
    Size: No Module Installed
    Form Factor: Unknown
    Set: None
    Locator: ChannelB-DIMM0
    Bank Locator: BANK 2
    Type: Unknown
    Type Detail: None

Handle 0x0010, DMI type 19, 31 bytes
Memory Array Mapped Address
    Starting Address: 0x00000000000
    Ending Address: 0x001FFFFFFFF
    Range Size: 8 GB
    Physical Array Handle: 0x000D
    Partition Width: 1

Handle 0x0011, DMI type 20, 35 bytes
Memory Device Mapped Address
    Starting Address: 0x00000000000
    Ending Address: 0x001FFFFFFFF
    Range Size: 8 GB
    Physical Device Handle: 0x000E
    Memory Array Mapped Address Handle: 0x0010
    Partition Row Position: Unknown
    Interleave Position: 1
    Interleaved Data Depth: 1

Handle 0x0012, DMI type 21, 7 bytes
Built-in Pointing Device
    Type: Other
    Interface: PS/2
    Buttons: 2

Handle 0x0013, DMI type 22, 26 bytes
Portable Battery
    Location: Internal Battery
    Manufacturer: FUJITSU
    Manufacture Date:  
    Serial Number: 02A-Z210522000167Z
    Name: CP753347-01
    Chemistry: Lithium Ion
    Design Capacity: 45032 mWh
    Design Voltage: 10800 mV
    SBDS Version:  
    Maximum Error: Unknown
    OEM-specific Information: 0xFFFFFFFF

Handle 0x0014, DMI type 24, 5 bytes
Hardware Security
    Power-On Password Status: Disabled
    Keyboard Password Status: Not Implemented
    Administrator Password Status: Disabled
    Front Panel Reset Status: Not Implemented

Handle 0x0015, DMI type 32, 11 bytes
System Boot Information
    Status: No errors detected

Handle 0x0016, DMI type 43, 31 bytes
TPM Device
    Vendor ID: INTC
    Specification Version: 2.0
    Firmware Revision: 500.5
    Description: TPM Device
    Characteristics:
        TPM Device characteristics not supported
    OEM-specific Information: 0x00000000

Handle 0x0017, DMI type 126, 89 bytes
Inactive

Handle 0x0018, DMI type 126, 26 bytes
Inactive

Handle 0x0019, DMI type 131, 64 bytes
OEM-specific Type
    Header and Data:
        83 40 19 00 31 00 00 00 00 00 00 00 00 00 00 00
        F8 00 82 34 00 00 00 00 01 00 00 00 00 00 0D 00
        3A 06 28 00 00 00 00 00 FE 00 FF FF 00 00 00 00
        00 FF 00 00 26 00 00 00 76 50 72 6F 00 00 00 00

Handle 0x001A, DMI type 143, 16 bytes
OEM-specific Type
    Header and Data:
        8F 10 1A 00 00 5F 46 4A 5F 4F 45 4D 5F 12 00 00

Handle 0x001B, DMI type 143, 8 bytes
OEM-specific Type
    Header and Data:
        8F 08 1B 00 01 03 00 00

Handle 0x001C, DMI type 143, 11 bytes
OEM-specific Type
    Header and Data:
        8F 0B 1C 00 02 00 01 38 04 80 07

Handle 0x001D, DMI type 143, 11 bytes
OEM-specific Type
    Header and Data:
        8F 0B 1D 00 02 06 01 09 E5 00 07

Handle 0x001E, DMI type 143, 7 bytes
OEM-specific Type
    Header and Data:
        8F 07 1E 00 02 01 01

Handle 0x001F, DMI type 143, 7 bytes
OEM-specific Type
    Header and Data:
        8F 07 1F 00 02 02 01

Handle 0x0020, DMI type 143, 11 bytes
OEM-specific Type
    Header and Data:
        8F 0B 20 00 02 07 01 03 01 00 00

Handle 0x0021, DMI type 143, 16 bytes
OEM-specific Type
    Header and Data:
        8F 10 21 00 03 02 01 02 01 00 00 00 00 00 00 00

Handle 0x0022, DMI type 143, 32 bytes
OEM-specific Type
    Header and Data:
        8F 20 22 00 03 06 01 02 0F 00 04 00 EC AF 00 00
        D0 AD 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Handle 0x0023, DMI type 143, 16 bytes
OEM-specific Type
    Header and Data:
        8F 10 23 00 03 0B 01 01 00 00 00 00 00 00 00 00

Handle 0x0024, DMI type 143, 16 bytes
OEM-specific Type
    Header and Data:
        8F 10 24 00 03 0D 01 01 01 00 02 03 00 00 00 00
    Strings:
        K5:SCBTE
        K7:FBE
        K7:FBD

Handle 0x0025, DMI type 176, 48 bytes
OEM-specific Type
    Header and Data:
        B0 30 25 00 10 00 00 00 00 00 FF FF FF FF FF FF
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        03 00 03 00 49 00 00 00 07 00 00 00 00 00 00 00

Handle 0x0026, DMI type 188, 8 bytes
OEM-specific Type
    Header and Data:
        BC 08 26 00 39 38 31 24

Handle 0x0027, DMI type 219, 106 bytes
OEM-specific Type
    Header and Data:
        DB 6A 27 00 01 04 01 45 02 00 90 06 01 10 82 20
        00 00 00 00 40 00 00 03 1F 00 00 C9 0A 44 44 02
        FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
        FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00
    Strings:
        MEI1
        MEI2
        MEI3
        MEI4

Handle 0x0028, DMI type 222, 14 bytes
OEM-specific Type
    Header and Data:
        DE 0E 28 00 01 99 00 03 10 01 20 02 30 03
    Strings:
        Memory Init Complete
        End of DXE Phase
        BIOS Boot Complete

Handle 0x0029, DMI type 248, 12 bytes
OEM-specific Type
    Header and Data:
        F8 0C 29 00 01 4C E0 00 92 03 00 00

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table

Here, we find an entry for the “Portable Battery” (Handle 0x0013) with some details. This is identical again for situations where the machine was booted with or without the adapter connected. The only difference is found in the “Header and Data” block of Handle 0x0027.

Has anyone an idea how to resolve this and make the battery information available to the Leap 15.3 system?
If needed, I can give more information.
Thank you.

2

Hi,

Just a guess: As you mentioned “outdated BIOS”, did you check if there is any setting in BIOS that might be blocking the information to the OS? Anything ACPI related? And I assume it is up to date?

3

No definitive answer from me for this, since it may take vendor support to fix. However, this Manjaro tutorial discusses various ACPI kernel options that can be parsed to compensate for quirky BIOS/UEFI. That means the BIOS/UEFI does not always understand the calls being sent to it by the OS. Sometimes, it might be necessary to “fool” the laptop’s firmware into believing a given OS is installed. Linux can mimic the acpi calls sent by another OS. Kernel boot parameter examples…

acpi_osi=Linux

acpi_osi='Windows 2018'

Experimentation would be needed.

4

I have this problem too in SuSE 15.3 and an older Asus laptop that came with Win8. The thing is KDE knows there is a battery or charging because if I unplug the cable it will chime at me. But no battery logo. It also has settings for what to do if on a low battery, and IIRC, those don’t appear if you don’t have a battery at all.

5

Thanks for the replies so far.
There is no indication in the BIOS menu whatsoever for ACPI related configurations.
The machine has just recently be delivered, I installed Leap 15.3 when it was just taklen out of the box. The BIOS date is as given in the original post. I can not find any information about an ungrade of the BIOS on the Fujitsu website. So, it is my guess, that the BIOS is recent.
I will try the acpi-related kernel parameters for boot. It may take me some time, but I will report back what happens.

6

Possibly too new hardware for 5.9 kernel.
Try to use TW or Leap with kernel from Kernel:stable:Backport repo.

7

Just logged into a icewm session, and the battery logo is there, you should check that out first. I couldn’t find a specific package for plasma 5 for battery stuff, but that doesn’t mean much.

8

You checked it with the same hardware as OP used?

9

I tried this, but no luck. No battery logo present in an icewm session.

I was not able to test the other suggestions yet.

10

Well it just rules out it being KDE’s fault and not the laptop, just in case. And as they replied, yes, it isn’t KDE’s fault.

For me though it is just weird I don’t have a battery logo show up. Rather annoying, and this is all I could find out about it.

11

Of the various suggestions, I first tried to add the acpi_osi boot parameter, because this seemed to be least disruptive.

I checked which Windows osi strings are available:

> sudo strings /sys/firmware/acpi/tables/DSDT |grep -i windows
[sudo] Passwort für root:
Windows 2001
Windows 2001 SP1
Windows 2001 SP2
Windows 2001.1
Windows 2006
Windows 2009
Windows 2012
Windows 2013
Windows 2015

and tested all of them, but in none of the cases there was any change in the outcome: no battery is detected even when booting with the acpi_osi strings.

So, next step would be to use a more recent kernel, as suggested. I think, using a Tumbleweed Live stick might be the next possible step. Let’s see what happens.

12

Now I tried the Tumbleweed KDE Live snapshot 20210916: but still the battery is not detected. This snapshot uses kernel version 5.14.2-1. Inside Tumbleweed the same symptoms (dmesg line for battery shows “battery absent”, upower -d does not show a battery) appear. So, I gues there is no reason to get a more recent kernel version than the 5.3.18-59.19 that’s installed.

Do you have any other suggestions? Do you need more specific information?

13

Can only suggest creating bug report.

14

Well, yes, that might be necessary - but where? Fujitsu only certifies for Windows, so they will most certainly not handle requests from Linux users. On the other hand, we are not even sure what causes the problem, hardware, kernel, some other software … I would prefer to know more about the reasons for this missing function.
So, I am somehow lost …

In fact, the test results that I posted in the original post seem to indicate that acpi once detects the AC adapter’s state during boot, but then never reacts to any changes (unplugging or reinserting adapter). Why?
Also, it seems to check once for the battery in slot BAT1 - shouldn’t this be BAT0 in the first place (there is only one battery in the Lifebook) - and nothing else.
Is there a command to force checking the status from the running system?

15

The reason for this missing function is mismatch between what kernel expects and what hardware says. To know more you need to be familiar with kernel code that does it. To reach someone who is familiar with this code one possibility is to open bug report. You could of course try kernel development mailing lists (I would say linux-acpi@vger.kernel.org) as well.

but where?

You could check vanilla kernel (http://download.opensuse.org/repositories/Kernel:/vanilla/standard/) and if the problem is present there (likely), go to https://bugzilla.kernel.org/.

16

Thanks for the links. Maybe I’ll try the mailing list first.

For installing the vanilla kernel, can you give some advice?
I am usually using Yast for software installation. In this case, I would add the repository to my list, select the multiversion packages, and install the vanilla version in addition to the previously installed version (at present 5.3.18-59.19.1-x86_64 and 5.3.18-59.24.1-x86_64 (after doing a backup of the machine first, of course). In zypp.conf I keep kernel versions as:

multiversion.kernels = latest,latest-1,running

Should I comment this line for the time of testing?
Any other recommendations?

17

https://en.opensuse.org/SDB:Keep_multiple_kernel_versions

18

The problem with ACPI battery detection for the Fijitsu Lifebook A3510 persists even in Leap 15.4.

However, in the meantime, a blog entry appeared that suggests a solution. I have tried, and indeed could successfully solve the problem with some help from other web resources (https://ubuntu.com/blog/debug-dsdt-ssdt-with-acpica-utilities, https://forums.opensuse.org/showthread.php/480341-use-custom-dsdt, https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573). For those interested, I will give a brief account below.

You will need the acpica utilities as described (see package acpica in Yast). Essentially, one needs to update the DSDT table to support the battery detection and management.
I choose to work in a directory ~/hardware/acpi. There, I used the commands:

acpidump > acpi.log
acpixtract acpi.log
iasl -d dsdt.dat

which created a file dsdt.dsl.
I renamed the file to dsdt_updated_for_battery.dsl and and opened it

cp dsdt.dsl dsdt_updated_for_battery.dsl
vi dsdt_updated_for_battery.dsl

for editing:

  • deleted all lines before the DefinitionBlock (including the first line containing an error message)
  • incremented the hex number (last argument in the DefinitionBlock, 0x010A0000 → 0x010A0001
  • find a line with “OperationRegion (ERAM,” … and replace the whole line by “OperationRegion (ERAM, EmbeddedControl, Zero, 0x0100)”
  • find a line with “Device (BAT1)” und replace in this segment of the file “Return(BATP)” by “Return(0x1F)”

When recompiling with

sudo iasl -ta dsdt_updated_for_battery.dsl

23 error messages resulted, all related to “Name already exists in scope”. For each of these the relevant line numbers are given. According to this blog entry the respective External declarations at the beginning of the file were commented out. Recompilation resulted in zero errors and created a file dsdt_updated_for_battery.aml.
For the following steps (done as sudo), a thread from the openSuSSE forums was used, as well as a file 01_acpi taken from the blog that suggested the solution for the problem (possibly, the respective file from the openSuSE thread can also be used, without having to edit) and copied to /etc/grub.d. The file needs to be executable

chmod 755 01_acpi

In the file, the location of grub-mkconfig_lib must be correctly given, on Leap 15.4 it is /usr/share/grub2. This can set as ${pkgdatadir}/grub-mkconfig_lib.
I copied the updated aml file to /boot and

chmod 644 dsdt_updated_for_battery.aml

Finally, grub must be reconfigured:

grub-mkconfig -o /boot/grub2/grub.cfg

No errors occured and the output of the command contains: Found custom ACPI table … Indeed a respective section has been added to grub.cfg.

After reboot, the battery symbol is displayed and reacts to changes in the charging state etc.
Maybe this is of help to others that have this problem.