battery not detected by ACPI

[Thomas Frick]

On my freshly installed Fujitsu Lifebook A3510 now running kubuntu 21.10 with kernel 5.13.0-22-generic, there is an issue with the internal battery. When kernel boots up, ACPI isn't able to detect it correctly, see dmesg line:
[ 0.528105] ACPI: battery: Slot [BAT1] (battery absent)

But asking lshw for power devices, it says:
*-battery
       description: Lithium Ion Battery
       product: CP753347-01
       vendor: FUJITSU
       physical id: 1
       serial: 02A-Z201219003557Z
       slot: Internal Battery
       capacity: 45032mWh
       configuration: voltage=10,8V

I've updated the BIOS to latest version 1.12 already, with no better result. What is the problem here, and how can I fix it?
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: thomas 945 F.... pulseaudio
CasperMD5CheckResult: pass
CurrentDesktop: KDE
DistroRelease: Ubuntu 21.10
InstallationDate: Installed on 2021-12-31 (4 days ago)
InstallationMedia: Kubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
MachineType: FUJITSU CLIENT COMPUTING LIMITED LIFEBOOK A3510
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-22-generic root=UUID=a67d854d-1ecf-4957-9b10-0204e42bbab0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
RelatedPackageVersions:
 linux-restricted-modules-5.13.0-22-generic N/A
 linux-backports-modules-5.13.0-22-generic N/A
 linux-firmware 1.201.3
Tags: impish
Uname: Linux 5.13.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/22/2021
dmi.bios.release: 1.12
dmi.bios.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.bios.version: Version 1.12
dmi.board.name: FJNBB6D
dmi.board.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.board.version: EQAB073106
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.ec.firmware.release: 1.9
dmi.modalias: dmi:bvnFUJITSUCLIENTCOMPUTINGLIMITED:bvrVersion1.12:bd09/22/2021:br1.12:efr1.9:svnFUJITSUCLIENTCOMPUTINGLIMITED:pnLIFEBOOKA3510:pvr:rvnFUJITSUCLIENTCOMPUTINGLIMITED:rnFJNBB6D:rvrEQAB073106:cvnFUJITSUCLIENTCOMPUTINGLIMITED:ct10:cvr:skuSK00:
dmi.product.family: LIFEBOOK-FTS
dmi.product.name: LIFEBOOK A3510
dmi.product.sku: SK00
dmi.sys.vendor: FUJITSU CLIENT COMPUTING LIMITED

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1956177/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Paul White (paulw2u)]

There is no 'kernel-package' package in the impish release. Moving bug report to 'linux' which is the correct package for the Linux kernel.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1956177

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Thomas Frick (thomas118)]

apport information

[Patrick Walz (flyingbackstein)]

Just created an account to comment on this

Seems to be BIOS related.
We received just shy of 1000 A3510s, split up into multiple shipments. The first 4 shipments (around 500 of them) arrived with BIOS V1.04 and had everything working fine. The latest and last shipment arrived with V1.10 and is plagued by the same issue.
Unfortunately Firmware Rollback to V1.04 is not possible since Fujitsu never released that version to the public. Only V1.09, V1.10 and V1.12 are available for Download, none of them being the solution.
We still had one Lifebook with 1.04 around so I checked before updating the BIOS and the battery was properly detected, after flashing 1.12 the battery was reported as absent.

This also does not only affect Ubuntu or Mint (which we use). I have also seen threads in the forums of Arch, SuSE and (I believe) Gentoo reporting the same.

[Patrick Walz (flyingbackstein)]

I managed to rudimentarily fix it via DSDT. So far everything seems to be in working order.
I will attached three aml files for BIOS Revisions 1.09, 1.10, 1.12 and another required file 01_acpi.

One of the aml files needs to be copied into /boot (acording to your BIOS Rev.) and renamed into dsdt.aml, 01_acpi needs to be copied to /etc/grub.d/
Follow this with update-grub, reboot and the battery symbol should be there.

[Thomas Frick (thomas118)]

Hello Patrick,

having time today I've applied your patch to my system, but the battery is still not recognized by OS. According to my BIOS rev. I've copied-renamed the one .aml file starting with "12_" to /boot/dsdt.aml, copied and chmod'ed 01_acpi to /etc/grub.d/ and ran update-grub, which told me that it "Found custom ACPI table: /boot/dsdt.aml". After rebooting the system (and being curious what happens), there is no battery symbol but text as before stating "No Batteries Available". Any idea what went wrong?

Anyway, thanks a lot for your assistance so far. :)

[Patrick Walz (flyingbackstein)]

Hello Thomas,

that's odd, I did 20 Lifebooks on Thursday and all of them worked.
I'd guess you have a different hardware configuration, so my dsdt.aml isn't applied properly ... :/

I'll try to whip up a tutorial including what I did so you can decompile the DSDT of your Lifebook and try with that one.

Going to get back to you tomorrow when I'm at work, since I didn't bring one of our Lifebooks home over the weekend.

Have nice sunday my friend :)

[Patrick Walz (flyingbackstein)]

Hello Thomas,

here`s how I did it, step by step.

1) install acpica-tools
apt-get install acpica-tools

2) Grab the DSDT of your device
cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

3) Decompile the dsdt.dat
iasl -d dsdt.dsl

4) Open the dsdt.dsl with whatever editor tickles your fancy
e.g. xed dsdt.dsl

5) Delete everything with a * in front, first line should be "DefinitionBlock"

6) Raise the last number in Definition Block by one
e.g.:
DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010C0000)
                                                               ↓
DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010C0001)

7) Search for the string "OperationRegion (ERAM"
for me it was at line 18751; your mileage may vary

8) Replace the entire line with this one:
perationRegion (ERAM, EmbeddedControl, Zero, 0x0100)

9) Save and Exit

10) Recompile the dsdt.dsl (Note: This WILL show loads of errors and optimizations, I didn get to read into those yet)
This will give you a dsdt.aml that should work.

11) Proceed as above

Hope this one will work, have a good one :)

[Patrick Walz (flyingbackstein)]

Quick edit for a typo:

in number 8) it should of course be :
OperationRegion and not perationRegion ...

And the recompile will throw warnings not errors ...

Sorry about that I am in a bit of a hurry ^^*

[Nikola Glavina (branisha)]

Patrick, I just want to say a big “Thank You”. I have been struggling with this issue for about two months. Your DSDT files haven't worked on my laptop, even my touchpad stopped working after I applied it lol. What did work was dumping my own dsdt, decompiling and updating it, and recompiling it according to your instructions. I guess A3510 comes with a couple of variations, some have i3 cpu, some i5. Thanks again and cheers!

[Patrick Walz (flyingbackstein)]

Hello Nikola,

glad I could help :) Took me about 3 or 4 months myself to figure out what was up

I already assumed that the files I provided won't work on every system after Thomas tried them, ours are i3/8GB/256GB across the board so I can mass deploy the patch with ease. I ran into the Touchpad error myself, when the BIOS version was different.

Best bet for everyone else would probably be the recompile as above

Cheers :D

[Pina Mahn (pinamahn2)]

Since you all are large customers buying 1000s of Lifebook A3510 could you please report it to fujitsu deutschland. Hope they will fix these.

Filed a bug in the fujitsu forum https://forum.ts.fujitsu.com/forum/viewtopic.php?f=65&t=49256

[Kevin Peter Gade (kgade)]

Hello.
I have tried to follow above instructions carefully, recompiling my own file. However for me its not working, unfortunately battery is still not recognized.

I followed these steps:

1) install acpica-tools
sudo apt-get install acpica-tools

2) Grab the DSDT of your device
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

3) Decompile the dsdt.dat
sudo iasl -d dsdt.dat

4) Open the dsdt.dsl with whatever editor tickles your fancy
sudo xed dsdt.dsl

5) Delete everything with a * in front, first line should be "DefinitionBlock"
(For me that include Firmware Error (ACPI) in line 1 and 2 - if that could matter:
Could not resolve [^GFX0.CLID], AE_NOT_FOUND (20190509/dswload-388)
Could not resolve [^GFX0.CLID], AE_NOT_FOUND (20190509/dswload2-369)

6) Raise the last number in Definition Block by one
e.g.:
DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010C0000)
                                                               ↓
DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010C0001)

7) Search for the string "OperationRegion (ERAM"
for me it was at line 18751; your mileage may vary

8) Replace the entire line with this one:
OperationRegion (ERAM, EmbeddedControl, Zero, 0x0100)

(I had OperationRegion (ERAM, SystemMemory, 0xFE508300, 0x0100) to begin with)

9) Save and Exit

10) Recompile the dsdt.dsl (Note: This WILL show loads of warnings and optimizations
This will give you a dsdt.aml that should work.

I did that with: sudo iasl -ta dsdt.dsl and got the aml file just with warnings.

11) Proceed as above

sudo cp dsdt.aml /boot/
sudo cp 01_acpi /etc/grub.d/
chmod 755 01_acpi
sudo update-grub
reboot

Still just the same :/
Can anyone point me in the right direction?

Running Linux Mint 20.3 Mate
PS. BIOS v. 1.12 (freshly update through Windows, Fujitsu DeskUpdate).

Br. Kevin

[Kai-Heng Feng (kaihengfeng)]

Seems like BATD is not correct?

Can someone please run
$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATD'

and attach its value?

[Kevin Peter Gade (kgade)]

Unfortunately I get an "Operation not permitted" error when I try to run acpidbg here. Is above command exactly as it should be entered? Thanks.

[Kai-Heng Feng (kaihengfeng)]

Ok, can you please run the following instead:
$ sudo acpidbg -b 'ex \_SB_.BAT1._STA'

[Kevin Peter Gade (kgade)]

Hi,
I left the PC at the office. Will try the new command on Friday when I will be there again. Thanks!
Br. Kevin

[Kevin Peter Gade (kgade)]

Unfortunately I get an "Operation not permitted" error when running sudo acpidbg -b 'ex \_SB_.BAT1._STA' as well.

[Kai-Heng Feng (kaihengfeng)]

Right, I think Secureboot needs to be disabled in order to use acpidbg.

[Kevin Peter Gade (kgade)]

Yes - Disabling Secureboot worked in order to get acpidbg working (killed my touchpad mouse however that is another topic).

Output from both commands here:

$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATD'
Evaluating \_SB_.PCI0.LPCB.EC0_.BATD
Evaluation of \_SB_.PCI0.LPCB.EC0_.BATD returned object 00000000a3ce38e0, external buffer length 18
 [Integer] = 0000000000000000

$ sudo acpidbg -b 'ex \_SB_.BAT1._STA'
Evaluating \_SB_.BAT1._STA
Evaluation of \_SB_.BAT1._STA returned object 00000000cb8c88ff, external buffer length 18
 [Integer] = 000000000000000F

[Kai-Heng Feng (kaihengfeng)]

Thanks! Can you please also run

$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATL'

$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATH'

[Kevin Peter Gade (kgade)]

$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATL'
Evaluating \_SB_.PCI0.LPCB.EC0_.BATL
Evaluation of \_SB_.PCI0.LPCB.EC0_.BATL returned object 0000000009af25b3, external buffer length 18
 [Integer] = 0000000000000000

$ sudo acpidbg -b 'ex \_SB_.PCI0.LPCB.EC0_.BATH'
Evaluating \_SB_.PCI0.LPCB.EC0_.BATH
Evaluation of \_SB_.PCI0.LPCB.EC0_.BATH returned object 000000003c0aee1f, external buffer length 18
 [Integer] = 0000000000000000

[Kai-Heng Feng (kaihengfeng)]

Thanks. Please attach `sudo cat /proc/iomem`.

[Kevin Peter Gade (kgade)]

Please find output of cat /proc/iomem attached.

[Kai-Heng Feng (kaihengfeng)]

And also full dmesg, thanks!

[Kevin Peter Gade (kgade)]

Output of dmesg attached.

[Kai-Heng Feng (kaihengfeng)]

I don't see anything wrong from the log. Has anyone tried mainline kernel?
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18/amd64/

[Pina Mahn (pinamahn2)]

A humble request: Just to reiterate myself, please post more comments on the official thread of fujitsu. Hope some engineers wake up! (also in English)

https://forum.ts.fujitsu.com/forum/viewtopic.php?f=65&t=49256

[Kevin Peter Gade (kgade)]

We have tested with 5.18.0-051800-generic now, unfortunately battery is still not recognized :(

Anything else we can try? Seems like some has managed to solve this with identical hardware, but then I must be missing some steps here. Any help is much appreciated.

[Kai-Heng Feng (kaihengfeng)]

When a battery is present, '\_SB_.BAT1._STA' should return 0x1f, but right now it returns 0xf. And it's because '\_SB_.PCI0.LPCB.EC0_.BATD' is 0. '\_SB_.PCI0.LPCB.EC0_.BATD' is something directly from firmware, so I _guess_ it's either 1) a firmware bug, or 2) special battery driver is required to let EC detect battery correctly.

[Kai-Heng Feng (kaihengfeng)]

So IMO the easiest workaround is to use DSDT/SSDT overlay to patch '\_SB_.BAT1._STA' and let it return 0x1f.

[Kevin Peter Gade (kgade)]

Could you put together a simple instruction for how to perform this workaround please? I am not sure, if this is what was supposed to be set by editing dsdt.dsl with above suggestion or if this is a new fix.

In all cases a simple instruction would be much appreciated and I will test this and get back with the result asap.

Thanks!

[Kai-Heng Feng (kaihengfeng)]

Here's a great guide:
https://www.kernel.org/doc/html/latest/admin-guide/acpi/initrd_table_override.html

Here's the ASL in DSDT:
            Device (BAT1)
            {
                Name (BATP, 0x0F)
                Method (_STA, 0, NotSerialized) // _STA: Status
                {
                    Return (BATP) /* \_SB_.BAT1.BATP */
                }

Change 'Return (BATP)' to 'Return (0x1F)', and follow the guide to patch DSDT.

[Kevin Peter Gade (kgade)]

The latest workaround worked!
Battery now shows up and after test it seems like status etc. is registered correctly.

So in the end I followed the steps in #36 with the additional patch to '\_SB_.BAT1._STA'.

Thank you so much for your help!

Br. Kevin

[Kai-Heng Feng (kaihengfeng)]

This series may fix the issue:
https://<email address hidden>/

Here's the kernel with the fix:
https://people.canonical.com/~khfeng/acpi-ec-fix/

[Pina Mahn (pinamahn2)]

Does it mean this patch fixes the bug and DSDT patches are NOT needed? Thanks

Ref: https://lore.kernel.org/linux-acpi/20220615195643.12608-1-hdegoede

[Pina Mahn (pinamahn2)]

Update: FUJITSU firmware Version 1.14 date: 09/05/2022

instructions for ubuntu jammy

1. Disable Secure Boot
2. Follow #36 comment

root@lifebook:~# diff dsdt.dsl.orig dsdt.dsl
1,21c1
< /*
< * Intel ACPI Component Architecture
< * AML/ASL+ Disassembler version 20200925 (64-bit version)
< * Copyright (c) 2000 - 2020 Intel Corporation
< *
< * Disassembling to symbolic ASL+ operators
< *
< * Disassembly of dsdt.dat, Wed Nov 30 14:33:29 2022
< *
< * Original Table Header:
< * Signature "DSDT"
< * Length 0x0002C002 (180226)
< * Revision 0x02
< * Checksum 0xE8
< * OEM ID "FUJ "
< * OEM Table ID "FJNBB6D "
< * OEM Revision 0x010E0000 (17694720)
< * Compiler ID "FUJ "
< * Compiler Version 0x00000001 (1)
< */
< DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010E0000)
---
> DefinitionBlock ("", "DSDT", 2, "FUJ ", "FJNBB6D ", 0x010E0001)
18771c18751
< OperationRegion (ERAM, SystemMemory, 0xFE508300, 0x0100)
---
> OperationRegion (ERAM, EmbeddedControl, Zero, 0x0100)

(ubuntu jammy)

For me it was not needed to change the parameter '\_SB_.BAT1._STA'

[Bora Ayvaz (borayvaz)]

Still having this issue on my pc

[Pina Mahn (pinamahn2)]

This lifebook is obscure model and fujitsu will not fix the bug. Editing dsdt.dsl is the only option. I don't think ubuntu/kernel can fix this.

At the same time, an user in https://forum.ts.fujitsu.com/forum/viewtopic.php?f=65&t=49256&p=156905#p156905 reports that the bug does not exist in Linux Mint.

[Kai-Heng Feng (kaihengfeng)]

Does the issue still present on mainline kernel?

[Bora Ayvaz (borayvaz)]

Yesterday i tried linux mint 21.1 on 1.14 bios its still exist

Also i talked with fujitsu support and they told me your product not supporting linux and theres no new bios coming

I dont know german but they saying 1.12 bios in linux mint doesnt have the bug?

Edit: Now i tried ubuntu 23.04 with 6.2 kernel and problem fixed it shows battery percantage charging/not charging thanks to everyone probably 6.0 kernel fixes this problem