Battery status reported incorrectly but NOT asus

cfr · 2022-09-06 02:47:41

I have probably not used my laptop on battery for a couple of weeks. Yesterday, I used it on battery and just now plugged into AC. I plugged in when both batteries were at 5% charge.

Immediately on plugging in, BAT0 jumped to 100% which is clearly rubbish. BAT1 appears to be reporting charge correctly.

I assumed this was the issue I'd seen discussed https://bbs.archlinux.org/viewtopic.php?id=278933 (reported at https://bugs.archlinux.org/task/75653?p … ned=37867) but, on reading the thread, I found it is specific to Asus laptiops. I also found https://bbs.archlinux.org/viewtopic.php?id=277534, but that seems too early to be the issue I'm seeing if it is due to an upgrade and doesn't match the symptoms I'm seeing as the problem there seemed to be the capacity was reported incorrectly whereas that's not what I'm seeing.

Basically, capacities, full energy at design and full energy now are reported correctly, but the current energy level is reported wildly incorrectly for the internal battery (BAT0), although it looks correct for the removable battery (BAT1). I'm assuming the charging status is accurate and BAT0 is not charging, though I obviously want it to, but I'm not sure how to verify this.

kernel:

5.19.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 29 Aug 2022 15:51:05 +0000 x86_64 GNU/Linux

/sys/ stuff:

/sys/class/power_supply/BAT0/alarm
665000
/sys/class/power_supply/BAT0/capacity
100
/sys/class/power_supply/BAT0/capacity_level
Full
/sys/class/power_supply/BAT0/charge_behaviour
[auto] inhibit-charge force-discharge
/sys/class/power_supply/BAT0/charge_control_end_threshold
100
/sys/class/power_supply/BAT0/charge_control_start_threshold
0
/sys/class/power_supply/BAT0/charge_start_threshold
0
/sys/class/power_supply/BAT0/charge_stop_threshold
100
/sys/class/power_supply/BAT0/cycle_count
315

The readings which concerned me initially:

/sys/class/power_supply/BAT0/energy_full
13300000
/sys/class/power_supply/BAT0/energy_full_design
23200000
/sys/class/power_supply/BAT0/energy_now
13300000

/sys/class/power_supply/BAT0/manufacturer
SONY
/sys/class/power_supply/BAT0/model_name
45N1111
/sys/class/power_supply/BAT0/power_now
0
/sys/class/power_supply/BAT0/present
1
/sys/class/power_supply/BAT0/serial_number
13210
/sys/class/power_supply/BAT0/status
Full
/sys/class/power_supply/BAT0/technology
Li-poly
/sys/class/power_supply/BAT0/type
Battery
/sys/class/power_supply/BAT0/uevent
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-poly
POWER_SUPPLY_CYCLE_COUNT=315
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=11396000
POWER_SUPPLY_POWER_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=23200000
POWER_SUPPLY_ENERGY_FULL=13300000
POWER_SUPPLY_ENERGY_NOW=13300000
POWER_SUPPLY_CAPACITY=100
POWER_SUPPLY_CAPACITY_LEVEL=Full
POWER_SUPPLY_MODEL_NAME=45N1111
POWER_SUPPLY_MANUFACTURER=SONY
POWER_SUPPLY_SERIAL_NUMBER=13210
/sys/class/power_supply/BAT0/voltage_min_design
11100000
/sys/class/power_supply/BAT0/voltage_now
11396000

I'm assuming this means it is not charging, which is obviously especially bad.
For comparison:

/sys/class/power_supply/BAT1/alarm
2593000
/sys/class/power_supply/BAT1/capacity
34
/sys/class/power_supply/BAT1/capacity_level
Normal
/sys/class/power_supply/BAT1/charge_behaviour
[auto] inhibit-charge force-discharge
/sys/class/power_supply/BAT1/charge_control_end_threshold
100
/sys/class/power_supply/BAT1/charge_control_start_threshold
0
/sys/class/power_supply/BAT1/charge_start_threshold
0
/sys/class/power_supply/BAT1/charge_stop_threshold
100
/sys/class/power_supply/BAT1/cycle_count
449

Here are the corresponding readings which look OK.

/sys/class/power_supply/BAT1/energy_full
51470000
/sys/class/power_supply/BAT1/energy_full_design
71100000
/sys/class/power_supply/BAT1/energy_now
17570000

/sys/class/power_supply/BAT1/manufacturer
LGC
/sys/class/power_supply/BAT1/model_name
45N1738
/sys/class/power_supply/BAT1/power_now
32213000
/sys/class/power_supply/BAT1/present
1
/sys/class/power_supply/BAT1/serial_number
 1067
/sys/class/power_supply/BAT1/status
Charging
/sys/class/power_supply/BAT1/technology
Li-ion
/sys/class/power_supply/BAT1/type
Battery
/sys/class/power_supply/BAT1/uevent
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=449
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11220000
POWER_SUPPLY_VOLTAGE_NOW=12020000
POWER_SUPPLY_POWER_NOW=32213000
POWER_SUPPLY_ENERGY_FULL_DESIGN=71100000
POWER_SUPPLY_ENERGY_FULL=51470000
POWER_SUPPLY_ENERGY_NOW=17570000
POWER_SUPPLY_CAPACITY=34
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=45N1738
POWER_SUPPLY_MANUFACTURER=LGC
POWER_SUPPLY_SERIAL_NUMBER= 1067
/sys/class/power_supply/BAT1/voltage_min_design
11220000
/sys/class/power_supply/BAT1/voltage_now
12020000

Although I did not look at /sys earlier, KDE appeared to report battery levels as I expected. I plugged in when KDE alerted me to at 5%. I became concerned when KDE reported an instant jump to 25% because 'Battery 2' had allegedly gone from 5% to 100% in moments. (I don't know why it calls BAT0 'Battery 2' and BAT1 'Battery'.)

The journal contains lines such as

Med 05 13:27:05 MyComputer root[19446]: ACPI action undefined: PNP0C0A:01
Med 05 13:27:05 MyComputer root[19448]: arg1 is battery, arg2 is PNP0C0A:01, arg3 is 00000080 and arg4 is 00000001

Med 06 02:49:46 MyComputer root[29445]: ACPI action undefined: PNP0C0A:00
Med 06 02:49:46 MyComputer root[29450]: arg1 is battery, arg2 is PNP0C0A:00, arg3 is 00000080 and arg4 is 00000001
Med 06 02:49:46 MyComputer root[29452]: ACPI action undefined: PNP0C0A:00
Med 06 02:49:46 MyComputer root[29454]: arg1 is battery, arg2 is PNP0C0A:00, arg3 is 00000080 and arg4 is 00000001
Med 06 02:49:47 MyComputer org_kde_powerdevil[8321]: kf.notifications: Could not notify  "pluggedin" by taskbar, notification has no associated widget
Med 06 02:49:47 MyComputer root[29572]: ACPI action undefined: ACPI0003:00
Med 06 02:49:47 MyComputer root[29577]: AC plugged
Med 06 02:49:47 MyComputer acpid[29578]: TLP started in battery mode (manual).
Med 06 02:49:47 MyComputer root[29693]: arg1 is ac_adapter, arg2 is ACPI0003:00, arg3 is 00000080 and arg4 is 00000001
Med 06 02:49:47 MyComputer root[29695]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Med 06 02:49:47 MyComputer root[29697]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006030
Med 06 02:49:47 MyComputer root[29699]: ACPI group/action undefined: thermal_zone / LNXTHERM:00
Med 06 02:49:47 MyComputer root[29701]: arg1 is thermal_zone, arg2 is LNXTHERM:00, arg3 is 00000081 and arg4 is 00000000

Aside from the fact that a non-existent second fan is reported as running (which my some programme started claiming some while ago), the output from sensors looks normal enough

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +45.0°C  

thinkpad-isa-0000
Adapter: ISA adapter
fan1:           0 RPM
fan2:        65535 RPM
CPU:          +45.0°C  
GPU:              N/A  
temp3:         +0.0°C  
temp4:         +0.0°C  
temp5:         +0.0°C  
temp6:         +0.0°C  
temp7:         +0.0°C  
temp8:         +0.0°C  

nvme-pci-0400
Adapter: PCI adapter
Composite:    +24.9°C  (low  = -273.1°C, high = +69.8°C)
                       (crit = +79.8°C)

BAT0-acpi-0
Adapter: ACPI interface
in0:          11.40 V  

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +46.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +44.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:        +43.0°C  (high = +100.0°C, crit = +100.0°C)

pch_skylake-virtual-0
Adapter: Virtual device
temp1:        +42.5°C  

BAT1-acpi-0
Adapter: ACPI interface
in0:          12.12 V  

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +45.0°C  (crit = +128.0°C)

In particular none of the temperatures are reported as 48, which I think would be the equivalent of 50 in the Asus thread and the CPU reading is 45 rather than 'N/A'.

With the LTS kernel, it still reports BAT0 as at 100%.

Med 06 04:03:51 MyComputer root[2193]: ACPI action undefined: PNP0C0A:01
Med 06 04:03:51 MyComputer root[2198]: arg1 is battery, arg2 is PNP0C0A:01, arg3 is 00000080 and arg4 is 00000001
Med 06 04:03:51 MyComputer root[2216]: ACPI action undefined: PNP0C0A:01
Med 06 04:03:51 MyComputer root[2225]: arg1 is battery, arg2 is PNP0C0A:01, arg3 is 00000080 and arg4 is 00000001
Med 06 04:03:51 MyComputer root[2298]: ACPI action undefined: ACPI0003:00
Med 06 04:03:52 MyComputer root[2303]: AC unplugged
Med 06 04:03:52 MyComputer acpid[2307]: TLP started in AC mode (manual).
Med 06 04:03:52 MyComputer root[2439]: arg1 is ac_adapter, arg2 is ACPI0003:00, arg3 is 00000080 and arg4 is 00000000
Med 06 04:03:52 MyComputer root[2441]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Med 06 04:03:52 MyComputer root[2443]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006030
Med 06 04:03:52 MyComputer root[2445]: ACPI group/action undefined: thermal_zone / LNXTHERM:00
Med 06 04:03:52 MyComputer root[2447]: arg1 is thermal_zone, arg2 is LNXTHERM:00, arg3 is 00000081 and arg4 is 00000000

I'm not sure why TLP starts in battery mode when I plug in and AC mode when I unplug?

I'm kind of worried this might be hardware if I'm seeing it with both kernels, but it seems a bit bizarre?

Should I be using acpi_call-dkms rather than acpi_call with the current kernel and acpi_call(-lts) only for the LTS kernel? The TLP wiki page suggests something like this, but it seems a bit out of date (judging by the kernel versions).

EDIT: It's not actually stuck at 100% as it's now showing 99% for BAT0, but that's not plausible unless it never actually discharged in the first place (so the original 5% was spurious). I'm currently running on battery to see if I can get something saner when BAT1 drops sufficiently, though I'm not sure if this is the best thing to do. BAT1 always discharges first (until it drops to 5%) and charges second (until BAT0 is about 80% I think).

I did open the back of the laptop to clean out the fan during the very hot weather. (It was remarkably clean, actually, but I blew out the dust I could anyway.) I didn't touch anything else, but I disabled BAT0 in the firmware (and removed BAT1). But the behaviour seemed perfectly normal afterwards.

BAT0 gets reenabled automatically on plugging into AC and the laptop won't boot without it. I've also run on battery since then. It's possible I didn't notice a jump if I plugged in just before putting the machine to sleep, but that's not terribly likely.

However, that probably was the first time I'd disabled BAT0 since updating the firmware a while ago to solve/partially solve an unrelated(?) problem with the CPU temperature not being reported correctly, so I wouldn't want to rule out some connection.

EDIT: And, now it's behaving itself?!??

Last edited by cfr (2022-09-07 00:12:14)

Arch Linux

#1 2022-09-06 02:47:41

Battery status reported incorrectly but NOT asus

Board footer