Solved Toshiba Satellite Battery not showing status

I have a Toshiba Satellite L755-S5246 that I am configuring FreeBSD 11.2. Most everything is working, but I cannot get the system to show any battery information. I know the battery works - if I unplug the power, the computer stays on, and when Windows was installed, it did show battery information. It is an aftermarket battery, but I wouldn't think that would make a difference.
When I run acpiconf -i 0, this is what I get:

Code:
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
Low/warn granularity:    0 mWh
Warn/full granularity:    0 mWh
Model number:      
Serial number:      
Type:          
OEM info:      
State:            not present
Present voltage:    unknown

When I run sysctl -a | grep -i battery, this is what I get:

Code:
hw.acpi.battery.info_expire: 5
hw.acpi.battery.units: 1
hw.acpi.battery.state: 7
hw.acpi.battery.time: -1
hw.acpi.battery.life: -1
dev.battery.0.%parent: acpi0
dev.battery.0.%pnpinfo: _HID=PNP0C0A _UID=1
dev.battery.0.%location: handle=\_SB_.BAT1
dev.battery.0.%driver: battery
dev.battery.0.%desc: ACPI Control Method Battery
dev.battery.%parent:

Using KSystemlog, I checked the system logs, and filtered for "ACPI" and got this:
Code:
26 Jul 2018 08:35:47    beastie    kernel    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>
26 Jul 2018 08:35:47    beastie    kernel    ACPI APIC Table: <TOSQCI TOSQCI00>
26 Jul 2018 08:35:47    beastie    kernel    acpi0: <TOSQCI TOSQCI00> on motherboard
26 Jul 2018 08:35:47    beastie    kernel    acpi0: Power Button (fixed)
26 Jul 2018 08:35:47    beastie    kernel    cpu0: <ACPI CPU> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    cpu1: <ACPI CPU> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    cpu2: <ACPI CPU> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    cpu3: <ACPI CPU> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
26 Jul 2018 08:35:47    beastie    kernel    atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
26 Jul 2018 08:35:47    beastie    kernel    attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
26 Jul 2018 08:35:47    beastie    kernel    Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
26 Jul 2018 08:35:47    beastie    kernel    acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
26 Jul 2018 08:35:47    beastie    kernel    acpi_ec0: <Embedded Controller: GPE 0x1e> port 0x62,0x66 on acpi0
26 Jul 2018 08:35:47    beastie    kernel    pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
26 Jul 2018 08:35:47    beastie    kernel    pci0: <ACPI PCI bus> on pcib0
26 Jul 2018 08:35:47    beastie    kernel    pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
26 Jul 2018 08:35:47    beastie    kernel    pci1: <ACPI PCI bus> on pcib1
26 Jul 2018 08:35:47    beastie    kernel    pcib2: <ACPI PCI-PCI bridge> at device 28.5 on pci0
26 Jul 2018 08:35:47    beastie    kernel    pci2: <ACPI PCI bus> on pcib2
26 Jul 2018 08:35:47    beastie    kernel    pcib3: <ACPI PCI-PCI bridge> at device 28.6 on pci0
26 Jul 2018 08:35:47    beastie    kernel    pci3: <ACPI PCI bus> on pcib3
26 Jul 2018 08:35:47    beastie    kernel    acpi_acad0: <AC Adapter> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    battery0: <ACPI Control Method Battery> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    acpi_button0: <Power Button> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    acpi_lid0: <Control Method Lid Switch> on acpi0
26 Jul 2018 08:35:47    beastie    kernel    atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0

Any help?
 
You may boot with verbose ON and check dmesg output for something like this: battery0: error fetching current battery info -- AE_NOT_FOUND or battery0: battery initialization failed, giving up

If you happend to see this than you could try next:
sudo acpidump -t -d > my.asl | grep _BIX

If there is output e.g.: \_SB.PCI0.BAT0._BIX you are likely to have the same issue I had, which is that my Huawei Matebook Pro X does not implement the _BIF function but _BIX in their DSDT.

You can find my workaround here: Workaround to use _BIX instead of _BIF
 
You may boot with verbose ON and check dmesg output for something like this: battery0: error fetching current battery info -- AE_NOT_FOUND or battery0: battery initialization failed, giving up

If you happend to see this than you could try next:
sudo acpidump -t -d > my.asl | grep _BIX

If there is output e.g.: \_SB.PCI0.BAT0._BIX you are likely to have the same issue I had, which is that my Huawei Matebook Pro X does not implement the _BIF function but _BIX in their DSDT.

You can find my workaround here: Workaround to use _BIX instead of _BIF

with verbose boot, this is what shows up for battery:
Code:
30 Jul 2018 21:11:04    beastie    kernel    battery0: <ACPI Control Method Battery> on acpi0
30 Jul 2018 21:11:04    beastie    kernel    random: harvesting attach, 8 bytes (4 bits) from battery0
30 Jul 2018 21:11:04    beastie    kernel    battery0: <Conexant CX20585 HDA CODEC> at cad 0 on hdac0
30 Jul 2018 21:11:57    beastie    kernel    battery0: battery initialization failed, giving up
I do find it interesting that battery0 referencing the Conexant codec. This could be part of the issue, and part of the issue I am having with sound. I'm not messing with the sound just yet, but if it is related, might take me down a good path.

I did run sudo acpidump -t -d > my.asl | grep _BIX, but got a message "Ambiguous output redirect"
I substituted "_BIX" with "_BIF" and got the same message.
 
I assume you did run the command in "tcsh" shell. Try with csh, bash or zsh.
If you don't have another shell than just run sudo acpidump -t -d > my.asl , than open the my.asl file in an editor of your choice and serarch for _BIX or _BIF.
 
The order is wrong.

sudo acpidump -t -d | grep _BIX > my.asl
That worked. The result is:
Code:
Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extended

for giggles, I substituted _BIF, and got
Code:
Method (_BIF, 0, NotSerialized)  // _BIF: Battery Information Extended

So I don't think this is the issue, but this might be going down the right path. I'm just not sure what step to take next.

Edit: Just for fun, I ran acpidump -t -d | grep Battery > my.asl, and this is what I got:
Code:
            Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */)  // _HID: Hardware ID
            Method (_BIF, 0, NotSerialized)  // _BIF: Battery Information
            Method (_BIX, 0, NotSerialized)  // _BIX: Battery Information Extended
            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
 
Ok. Now you know that there is at least a function declared which potentially returns information about your battery when called.
Still, your dmesg shows Battery initialization failed. The debug message comes from "acpi_cmbat_init_battery function", implemented here ( at the very bottom ): https://github.com/freebsd/freebsd/blob/master/sys/dev/acpica/acpi_cmbat.c.

As long as you can't get this function to succeed, your battery status will not work.
Concerning your next steps. You could try to place more debug messages in "acpi_cmbat_init_battery". E.g. one in each of the "if" Blocks to see where it is failing first.

E.g:
Code:
if (!acpi_BatteryIsPresent(dev) || !device_is_attached(dev)) {
        ACPI_SERIAL_END(cmbat);
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),    
             "battery Battery not found or not attached\n");
        continue;
} else {
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),    
             "battery Battery found \n");
}
 
I may wait on this for a bit. I have not done any source code modification before, so will need to do a fair bit of looking up information before going to make sure I don't mess things up. This is a learning project for me, so I'll tackle it at some point, but will table this issue for now. Thanks for the help!
 
You may boot with verbose ON and check dmesg output for something like this: battery0: error fetching current battery info -- AE_NOT_FOUND or battery0: battery initialization failed, giving up

If you happend to see this than you could try next:
sudo acpidump -t -d > my.asl | grep _BIX

If there is output e.g.: \_SB.PCI0.BAT0._BIX you are likely to have the same issue I had, which is that my Huawei Matebook Pro X does not implement the _BIF function but _BIX in their DSDT.

You can find my workaround here: Workaround to use _BIX instead of _BIF
Same bete with an Acer Spin 11
You may boot with verbose ON and check dmesg output for something like this: battery0: error fetching current battery info -- AE_NOT_FOUND or battery0: battery initialization failed, giving up

If you happend to see this than you could try next:
sudo acpidump -t -d > my.asl | grep _BIX

If there is output e.g.: \_SB.PCI0.BAT0._BIX you are likely to have the same issue I had, which is that my Huawei Matebook Pro X does not implement the _BIF function but _BIX in their DSDT.

You can find my workaround here: Workaround to use _BIX instead of _BIF
Same here with an Acer Spin 1. I 'll try to follow that workaround. But I've never compiled the kernel and report here If successful.
 
I wanted to give an update. The battery ended up completely dying, and after I replaced the battery, I am correctly reading battery status. So, even though the old battery was working, it was malfunctioning, and that is why I was having the problem.
 
Back
Top