Uninstall battery drivers equivalent of FreeBSD (like in Windows)

Hi,

Facing an issue with battery charging being stuck at a certain percentage - the solution is apparently doing an "uninstall" of the battery driver from "Device Manager" in windows.

What is the FreeBSD equivalent of uninstall/scan for changes that's done in Windows?
 
I don't know that FreeBSD has such a utility. But you can try:
apm
acpiconf
sysctl hw.acpi.battery
Hey thanks - i've used `apm` and `acpiconf` earlier - but not sure how to uninstall/reset the drivers to enable the battery to be charged again.

As you can see the output here from apm the inbuilt battery is stuck at 5% and external is stuck at 79% - they don't charge above that (53% is the max it goes upto)- only the external one seems to discharge, while the internal one at 5% is too low to even power on the machine on it's own

Code:
apm
APM version: 1.2
APM Management: Disabled
AC Line status: on-line
Battery Status: charging
Remaining battery life: 53%
Remaining battery time: unknown
Number of batteries: 2
Battery 0:
    Battery Status: charging
    Remaining battery life: 5%
    Remaining battery time: unknown
Battery 1:
    Battery Status: high
    Remaining battery life: 79%
    Remaining battery time: unknown

Any ideas what could be done? Don't have access to a Windows machine or spare hard drive to do this - would really prefer a FreeBSD-centric solution!
 
Seems a bit unlikely that uninstalling a driver that you've never installed on an operating system you never installed would impact battery life (unless some firmware involved and the machine used to have Windows ... maybe ...). I think you can boot Windows live images these days so that might be a quicker path to test this theory (uninstalling the driver) out?
 
Seems a bit unlikely that uninstalling a driver that you've never installed on an operating system you never installed would impact battery life (unless some firmware involved and the machine used to have Windows ... maybe ...).
The machine was used by someone else with a Windows installation earlier. The vendor website for the laptop also shows some drivers/firmware updates that are, mostly, for Windows.
I think you can boot Windows live images these days so that might be a quicker path to test this theory (uninstalling the driver) out?
I tried booting via Ventoy - but somehow it didn't allow me to boot into it, only showed the intallation options. Am I doing something wrong? (Haven't used windows in ages)

Was really hoping for a FreeBSD approach.
 
In the other thread you've opened I've seen that the laptops is a Lenovo T480. Did you try the reset button ( there is a small hole hidden under the laptop)? You can also try to discharge the static from your T480. If you haven't done that, it may fix the problem. To do this, first make sure that your laptop is completely powered off. Next unplug the device from the AC adapter. You will need to remove the external battery and then remove the back case, and finally the internal battery. Once the internal battery is removed, flip the computer over and press and hold the power button down for about 1 minute. Once you've done that, you can put your batteries back in, plug the charger back in, and finally turn your computer back on to see if that fixes your problem.
If the last method did not fix it then you should consider replacing the internal battery.
 
If "sysctl dev.battery.0.%desc" says "ACPI Control Method Battery", writing this to /boot/loader.conf should disable the battery driver on reboot:
debug.acpi.disabled="cmbat"

But the driver "only" reports battery statistics. It doesn't support options to influence charging (at least codewise).

... the solution is apparently doing an "uninstall" of the battery driver from "Device Manager" in windows.
Uninstalling windows drivers won't have an effect in FreeBSD. Only a bios/uefi update/downgrade could do that.

Apm is from the 90ies? Wasn't it removed? Better use "acpiconf -i 0" or sysctls.
 
Any ideas what could be done? Don't have access to a Windows machine or spare hard drive to do this - would really prefer a FreeBSD-centric solution!

You now have 2 threads running on this issue, which is confusing. I suggest posting yourcontent from

https://forums.freebsd.org/threads/weird-battery-problem-wont-charge-beyond-53-how-to-fix-it.92205/

to here and closing that one.

[edit] Too late, there are more replys there including one by cy@ which hopefully helps.[/edit]

So I watched the video, and apart from mentioning Windows drivers - irrelevant on FreeBSD - you should try the method he suggests, namely:

. shutdown, turn it off
. remove the external battery
. plug in the power
. boot

That should begin charging the internal battery from 10-11%.

. fully recharge it.
. unplug power, test it works
. shutdown
. reinstall external battery
. plug in the power
. WAIT to see if charging (LEDs)
. . if so, charge fully first
. . if not, proceed ...
. boot

any change?

Also, are you sure you're running the latest BIOS/ UEFI update from Lenovo? If not, flash the latest one (use Ventoy if no USB updater).

Worth a try?
 
As you can see the output here from apm the inbuilt battery is stuck at 5% and external is stuck at 79% - they don't charge above that (53% is the max it goes upto)- only the external one seems to discharge, while the internal one at 5% is too low to even power on the machine on it's own

How recently did this problem emerge, compared to when you tried setting the charge thresholds mentioned in your other thread, mid '23?

apm ... Battery Status: charging Remaining battery life: 53% Remaining battery time: unknown Number of batteries: 2 Battery 0: Battery Status: charging Remaining battery life: 5% Remaining battery time: unknown Battery 1: Battery Status: high Remaining battery life: 79% Remaining battery time: unknown

One advantage of apm() over acpiconf() is showing both batteries at once, however the Design and Last Full capacities of each battery is only shown by acpiconf, for one at a time.

So please show those data from:
acpiconf -i0 and
acpiconf -i1

(towards making sense of the relative 5% and 79% values)
 
Apm is from the 90ies? Wasn't it removed? Better use "acpiconf -i 0" or sysctls.

Mid '80s originally. My Compaq Armada 1500c laptop - needing a sturdy lap - died in service in 2019, after running as a small server since ~2001, 24/7/365 on solar power.

There'd be a few APM boxes still running I expect. As you see, the 'apm' command still reports battery and AC status, and 'zzz' has been remapped to 'acpiconf -s3' (suspend).
 
In the other thread you've opened I've seen that the laptops is a Lenovo T480. Did you try the reset button ( there is a small hole hidden under the laptop)?
Yes, I've tried pressing the reset button , for even upto 20 seconds - but it hasn't changed much wrt the battery charging situation.
You can also try to discharge the static from your T480. If you haven't done that, it may fix the problem....
Ok, I haven't tried this - will try to do the steps, quick q's :
I guess I should also disable the internal battery first?
Will I have to disconnect the cable of the internal battery and plug it in back as well?
If "sysctl dev.battery.0.%desc" says "ACPI Control Method Battery", writing this to /boot/loader.conf should disable the battery driver on reboot:
debug.acpi.disabled="cmbat"
Yes, it does say "ACPI Control Method Battery" - do you mean I should append
Code:
debug.acpi.disabled="cmbat"
to the loader.conf and try turning on the laptop? Should I remove it later?

UPDATE : Tried this with the loader.conf having that value and starting the laptop - I couldn't query using acpiconf -i0/1 as expected - then restarted the laptop and removed the same line - it didn't have any effect on that charging situation - still stuck at 53% (5%, 79% respectively for internal,external batteries). So this seems like a dead-end?
How recently did this problem emerge, compared to when you tried setting the charge thresholds mentioned in your other thread, mid '23?
Thanks for noticing :D - no I believe this is something that happened recently, maybe perhaps due to a bios/firmware update with ubuntu updates (on the 2nd disk) that I may have done - or perhaps before that - I'm not entirely sure what caused this, could have been from before the ubuntu update as well.
So please show those data from:
acpiconf -i0 and
acpiconf -i1
Sure, I still don't understand how 5% and 79% average out to be 53% 🤔, but that's an explanation I can live without, for now :
Code:
acpiconf -i0
Design capacity:    23940 mWh
Last full capacity:    2440 mWh
Technology:        secondary (rechargeable)
Battery Swappable Capability:    Non-swappable
Design voltage:        11400 mV
Capacity (warn):    122 mWh
Capacity (low):        200 mWh
Cycle Count:        959
Mesurement Accuracy:    95 %
Max Average Interval:    1000 ms
Min Average Interval:    500 ms
Low/warn granularity:    -1 mWh
Warn/full granularity:    -1 mWh
Model number:        01AV420
Serial number:         2080
Type:            LiP
OEM info:        LGC
State:            critical charging
Remaining capacity:    5%
Remaining time:        unknown
Present rate:        0 mW
Present voltage:    11662 mV

acpiconf -i1
Design capacity:    23940 mWh
Last full capacity:    4350 mWh
Technology:        secondary (rechargeable)
Design voltage:        11400 mV
Capacity (warn):    217 mWh
Capacity (low):        200 mWh
Cycle Count:        455
Mesurement Accuracy:    95 %
Max Average Interval:    1000 ms
Min Average Interval:    500 ms
Low/warn granularity:    -1 mWh
Warn/full granularity:    -1 mWh
Model number:        01AV490
Serial number:         2838
Type:            LiP
OEM info:        LGC
State:            high
Remaining capacity:    79%
Remaining time:        unknown
Present rate:        0 mW
Present voltage:    11789 mV

smithi
Also, are you sure you're running the latest BIOS/ UEFI update from Lenovo? If not, flash the latest one (use Ventoy if no USB updater).
Actually after the ubuntu update (2nd hard drive) I've noticed this error at boot time `(A7) Me FW Downgrade - Request MeSpiLock Failed` - not sure if it's related, but I suspect the timing of battery malfunction and this error are somewhat correlated - not that I think about it.
 
I guess I should also disable the internal battery first?
Will I have to disconnect the cable of the internal battery and plug it in back as well?
Yes, you have to disconnect both batteries, but my guess is that the internal battery is "fried" and needs to be replaced.
 
You can most likely disconnect the internal one from the BIOS. My A485 allows for this. Also, two days ago my A485 was locking a battery at 46%, so here is what I did. Reboot into BIOS, disable the internal battery. The machine will power off. Then remove the external battery, power it back on and then, when the system is bootet, insert the external one. It started charging after that. Hope that helps.
 
Reboot into BIOS, disable the internal battery. The machine will power off. Then remove the external battery, power it back on and then, when the system is bootet, insert the external one. It started charging after that. Hope that helps.
I had tried this method earlier - but at this point I will retry it again I guess.
 
What I can say is that your battery has close to 1000 cycles and is down to 10% of it's design capacity. It needs changing. I did that in my A485, the case started bulging because of blown up cells. The trouble is not worth the fourty bucks it costs.
 
UPDATE : Got 2 new external 61+ batteries and replaced internal battery!

Never going to face battery problems ever again in life!
 
UPDATE : Got 2 new external 61+ batteries and replaced internal battery!

When it's all charged, could you post acpiconf -i0 and -i1 while it's running on battery, after a while to settle.

This will confirm which battery is used first, show initial states and also show power used and an indication of duration on battery (assuming idle) - for your own records and our entertainment ;-)

Never going to face battery problems ever again in life!

Hopefully. You'll need to check state of charge on stored spare batteries every so many months.

I also suggest not playing with charge thresholds at first, so you can confirm standard conditions.

cheers, Ian
 
When it's all charged, could you post acpiconf -i0 and -i1 while it's running on battery, after a while to settle.
Here you go - something interesting/worrying - battery0 somehow doesn't charge more than 78-79% - weird 🤔 (having it plugged in since past 30 mins)
battery0 output :
Code:
Design capacity:    22800 mWh
Last full capacity:    16000 mWh
Technology:        secondary (rechargeable)
Battery Swappable Capability:    Non-swappable
Design voltage:        11400 mV
Capacity (warn):    800 mWh
Capacity (low):        200 mWh
Cycle Count:        3
Mesurement Accuracy:    95 %
Max Average Interval:    1000 ms
Min Average Interval:    500 ms
Low/warn granularity:    -1 mWh
Warn/full granularity:    -1 mWh
Model number:        01AV421
Serial number:           35
Type:            LiP
OEM info:        LGC
State:            high
Remaining capacity:    78%
Remaining time:        unknown
Present rate:        0 mW
Present voltage:    12174 mV
And for battery1 (this one doesn't seem to charge past 85% 🤔 ) :
Code:
Design capacity:    48840 mWh
Last full capacity:    40310 mWh
Technology:        secondary (rechargeable)
Design voltage:        11100 mV
Capacity (warn):    2015 mWh
Capacity (low):        200 mWh
Cycle Count:        13
Mesurement Accuracy:    95 %
Max Average Interval:    1000 ms
Min Average Interval:    500 ms
Low/warn granularity:    -1 mWh
Warn/full granularity:    -1 mWh
Model number:        01AV425
Serial number:        63839
Type:            LION
OEM info:        SANYO
State:            high
Remaining capacity:    85%
Remaining time:        unknown
Present rate:        0 mW
Present voltage:    12123 mV

This will confirm which battery is used first, show initial states and also show power used and an indication of duration on battery (assuming idle) -
It's not exactly idle - but my usualy workload of having a heavy browser session.
Hopefully. You'll need to check state of charge on stored spare batteries every so many months.
Somehow when I remove the battery charging adaptor the time left for batteries to discarge shows ~4 hrs and then will plummet to 2 something hrs. Is it due to the workload changing? Or the ripoff batteries acting weird?
I also suggest not playing with charge thresholds at first, so you can confirm standard conditions.
Yes - won't be changing any thresholds anytime soon.
But quick question : How do I make these batteries longer lasting?
1) Internal one : I guess this will be undergoing the most cycles of charge/discharge - how do I ensure that external one is used up before internal one dies with it's power? This will help change external one and not lose work (if internal is dead before, no option to change)
2) External ones : should I remove them when I'm plugged in?
 
Here you go - something interesting/worrying - battery0 somehow doesn't charge more than 78-79% - weird 🤔 (having it plugged in since past 30 mins)
battery0 output :
Code:
Design capacity: 22800 mWh
Last full capacity: 16000 mWh

Hmm, 16000 is only 70% of new design capacity, suggesting it has never (yet) been fully charged.

I'll have to get back to you later tonight here, but meanwhile can you boot Windows and run Vantage to examine the battery stats, both whole system and individually if that's offered?

Screenshots will do; I'd like to confim there are no charge thresholds set on these (presumably new) batteries, or whether previous settings were maybe stored elsewhere?

If there are any thresholds set, after taking screenshots, clear them altogether, charge fully and check again?
 
Ok booted into Windows

So this is a little weird - it shows charging lightning symbol in the icon but doesn't show charging for either of the batteries 🤔

1708109290269.png



then there is this screenshot from Lenovo Vantage Software on windows - battery thresholds seem to be fine - am I missing something?
1708109459210.png



So far been a few minutes and the charging percentages are the same as in the screenshot taken a few minutes back

UPDATE: Plugged it in - Went for a workout - for an hour - came back to see the same charge status - not a single percent charges while plugged in for an hour. Something is seriously amiss.
 
UPDATE: Plugged it in - Went for a workout - for an hour - came back to see the same charge status - not a single percent charges while plugged in for an hour. Something is seriously amiss.

Have you found the place in Vantage settings yet, that completely removes and cancels any non-default thresholds?

Never mind the longterm for now; I think until sorted out you need to get back to how it was before you set thresholds with that FreeBSD acpi_call method last year.

[edit] ... because despite replacing both batteries, it still retained those settings, somehow.
 
Back
Top