Hi, I noticed a strange phenomenon while trying to find out the power consumption of my notebook (HP Elitebook 850). While AC plugged in, the charging current is shown in /sys/class/power_class/BAT0/current_now, but when I unplug it, the current rate is unavailable: /sys/class/power_supply/BAT0# while /bin/true; do cat current_now; sleep 1; done --- with AC --- 254000 253000 253000 253000 --- unplug AC --- 0 cat: current_now: No such device cat: current_now: No such device cat: current_now: No such device cat: current_now: No such device cat: current_now: No such device --- plug AC --- 0 0 0 0 242000 290000 286000 285000 ^C I already "debugged" that in battery.c that for unplugged state the rate returned is indeed "-1", so the output above makes sense. I just wonder if it could report also the (more interesting) discharge current instead of the charging current. Is there some way to better debug this, eg. by manually reading the ACPI tables?
Created attachment 305679 [details] dsdt.dsl
I checked the _BST method with acpidbg (not going further) and it seems that it really returns -1: - Evaluate _SB_.BAT0._BST Evaluating \_SB_.BAT0._BST Evaluation of \_SB_.BAT0._BST returned object 0000000035df6af1, external buffer length 78 [Package] Contains 4 Elements: [Integer] = 0000000000000001 [Integer] = 00000000FFFFFFFF [Integer] = 0000000000000DD9 [Integer] = 0000000000003056 so I guess it's a firmware bug or a feature. The diagnosis of the UEFI Bios however is able to get the current within a few seconds. Maybe there is some proprietary way to get battery current. Closing.
I guess this one here is the FW bug (from \_SB_.PCI0.LPCB.EC0_.BTST) DerefOf (NBST [Arg0]) [Zero] = Local0 // Battery state If ((Local0 & One)) // discharging ? { // yes -> range check of current rate (local3) If (((Local3 < 0x0190) || (Local3 > 0x1964))) { // out of range? use old rate Local5 = DerefOf (DerefOf (NBST [Arg0]) [One]) // also out of range? If (((Local5 < 0x0190) || (Local5 > 0x1964))) { Local3 = 0x0D7A // 3450 } Else { Local3 = Local5 // old rate } } // ups, now always overwrite current rate with -1 ! Local3 = 0xFFFFFFFF } ElseIf (((Local0 & 0x02) == Zero)) // not charging? { Local3 = Zero } So, I guess clearly a FW bug, a direct call to \_SB_.PCI0.LPCB.EC0_.BPR_ gives the correct current while discharging and charging.