ACPI wrong battery information

raffobaffo · 2018-07-19 11:41:36

Hey everybody, I've made a fresh installation of arch+i3 on my ASUS-1001PX but i can't figure out why the ACPI reports wrong battery informations. If I type acpi -V i get:

Battery 0: Discharging, 100%, 4200:00:00 remaining
Battery 0: design capacity 4300 mAh, last full capacity 4200 mAh = 97%
Adapter 0: off-line
Thermal 0: ok, 60.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 98.0 degrees C
Thermal 0: trip point 1 switches to mode passive at temperature 95.0 degrees C
Cooling 0: Processor 0 of 10
Cooling 1: LCD 0 of 10
Cooling 2: Processor 0 of 10

That is not correct, on Manjaro with same acpi packet version and same boot commands it seems to work but i don't know why.
Thanks in advice for the help

TheSaint · 2018-07-19 12:10:33

You might try to compare the two distro settings.

skunktrader · 2018-07-19 12:28:44

I have the identical problem with an eeePc since upgrading to 4.17

ewaller · 2018-07-19 14:37:13

That is one hell of a battery you have there! Why change anything? As TheSaint points out, compare the config files of the kernels. What kernel was running when it worked on Manjaro?

raffobaffo · 2018-07-20 18:04:59

Following what skunktrader said I've realized that Manjaro uses the lts kernel. I've installed that and now the issue is fixed. Should I alert kernel developers about this issue with kernel 4.17?

ewaller wrote:

That is one hell of a battery you have there! Why change anything? As TheSaint points out, compare the config files of the kernels. What kernel was running when it worked on Manjaro?

Battery is the only good thing about this Atom N450 netbook but I have to admit that Arch gave a big boost to this otherwise useless peace of electronic

Last edited by raffobaffo (2018-07-20 18:08:02)

loqs · 2018-07-20 18:36:11

Would check if the issue is fixed in 4.18-rc5 first before contacting upstream.

julianmb · 2018-07-31 03:03:42

I've a similar problem, my battery is always charging:

Battery 0: Charging, 100%, until charged
Battery 0: design capacity 4300 mAh, last full capacity 4200 mAh = 97%
Adapter 0: on-line
Thermal 0: ok, 60.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 95.0 degrees C
Thermal 0: trip point 1 switches to mode passive at temperature 92.0 degrees C
Cooling 0: Processor 0 of 10
Cooling 1: Processor 0 of 10
Cooling 2: Processor 0 of 10
Cooling 3: LCD 0 of 10
Cooling 4: Processor 0 of 10

I already tried with the mainline kernel, but it doesn't fix the problem, only reverting to linux-lts fix it. My model is Asus EEEpc 1215p. Ani ideas?

ewaller · 2018-07-31 03:40:30

julianmb wrote:

Ani ideas?

Try configuring your bootloader to lie and tell the ACPI subsystem that you are running windows on the kernel command line using the acpi_os_name= switch.
https://wiki.archlinux.org/index.php/DS … of_Windows
https://www.kernel.org/doc/Documentatio … meters.txt

YMMV

julianmb · 2018-07-31 05:29:40

I have "acpi_osi=" on my kernel parameters already (to fix vacklight and fn keys), but I tried a lot of parameters just to check if it works:

removed acpi_osi parameter.
acpi_osi="!Windows2012".
acpi_osi="Windows 2000"
acpi_osi=Linux.
acpi_osi="!Windows2009".

Sadly nothing works, I guess that maybe im missing something? just to clarify, im updating my grub config after every change.

ewaller · 2018-07-31 14:00:28

In rereading my second link, it is not clear to me that acpi_osi= and acpi_os_name= are the same thing. It may not get you anywhere, but you still might try acpi_os_name=

R00KIE · 2018-07-31 18:14:29

The acpi utility does some questionable math* to obtain some of the values, I would get the information directly from /sys, look at the values and decide what's what. That remaining time looks just fine, if the battery reports a very very low discharge rate, like when you have the laptop being supplied by the charger, then doing the math most probably yields that value.

* For my laptop, to get the design capacity, acpi picks the energy_full_design value and divides it by the voltage_now value, this is "fun" to look at during charge or discharge as the reported value for design capacity will change.

raffobaffo · 2018-09-02 10:15:01

I've tryed looking at different files in /sys but voltage_now reports wrong informations and the system is not even able of understanding if the power supply is plugged or unpplugged.

ewaller · 2018-09-02 14:36:59

R00KIE wrote:

* For my laptop, to get the design capacity, acpi picks the energy_full_design value and divides it by the voltage_now value, this is "fun" to look at during charge or discharge as the reported value for design capacity will change.

That is mind boggling. Sounds like they are trying to convert Watt-Hrs to Amp-Hrs; badly.

raffobaffo · 2019-01-03 14:17:42

I don't know if three months are enough to consider this a necrobomb, in this case I apologize in advance. Since the day I made this post I have not been able to find a solution for this problem on newer kernels and in these days the lts kernel have been upgraded from 4.14 kernel to 4.19 so my "workaround" no longer works. Can someone suggest me anything to try to read correct values from acpi?

Thanks again for your precious help so far

seth · 2019-01-03 22:24:31

https://en.wikipedia.org/wiki/Procrastination

Let's check what platform modules are loaded:

lsmod

(The next step would be to check whether it provides the acpi data, the actual /sys/class/power_supply/ subpath might hint at that)

raffobaffo · 2019-01-04 11:16:22

lsmod shows that both ac and battery modules are loaded. Inside /sys/class/power_supply/BAT0 various informations are reported but are incorrect and does not change over time while the battery discharge.

seth · 2019-01-04 13:26:57

that both ac and battery modules

Please post the actual output, those are generic modules.

raffobaffo · 2019-01-05 11:14:54

Sorry, my bad. Here it is:

Module                  Size  Used by
ccm                    20480  3
i915                 2109440  2
uvcvideo              114688  0
videobuf2_vmalloc      20480  1 uvcvideo
videobuf2_memops       20480  1 videobuf2_vmalloc
arc4                   16384  2
videobuf2_v4l2         28672  1 uvcvideo
rt2800pci              16384  0
videobuf2_common       57344  2 videobuf2_v4l2,uvcvideo
rt2800mmio             16384  1 rt2800pci
kvmgt                  32768  0
videodev              229376  3 videobuf2_v4l2,uvcvideo,videobuf2_common
rt2800lib             126976  2 rt2800mmio,rt2800pci
vfio_mdev              16384  0
mdev                   24576  2 kvmgt,vfio_mdev
rt2x00pci              16384  1 rt2800pci
vfio_iommu_type1       32768  0
rt2x00mmio             16384  2 rt2800mmio,rt2800pci
vfio                   36864  3 kvmgt,vfio_mdev,vfio_iommu_type1
rt2x00lib              81920  5 rt2x00mmio,rt2x00pci,rt2800mmio,rt2800pci,rt2800lib
media                  57344  4 videodev,videobuf2_v4l2,uvcvideo,videobuf2_common
kvm                   741376  1 kvmgt
joydev                 28672  0
mac80211              946176  3 rt2x00pci,rt2x00lib,rt2800lib
mousedev               24576  0
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
asus_wmi               32768  0
wmi_bmof               16384  0
sparse_keymap          16384  1 asus_wmi
irqbypass              16384  1 kvm
i2c_algo_bit           16384  1 i915
cpufreq_ondemand       16384  2
drm_kms_helper        208896  1 i915
snd_hda_codec_realtek   122880  1
snd_hda_codec_generic    90112  1 snd_hda_codec_realtek
snd_hda_intel          49152  0
snd_hda_codec         155648  3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
cfg80211              778240  2 rt2x00lib,mac80211
drm                   499712  4 drm_kms_helper,i915
snd_hda_core           98304  4 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
coretemp               20480  0
snd_hwdep              16384  1 snd_hda_codec
psmouse               172032  0
snd_pcm               135168  3 snd_hda_intel,snd_hda_codec,snd_hda_core
input_leds             16384  0
pcspkr                 16384  0
i2c_i801               36864  0
snd_timer              40960  1 snd_pcm
snd                   102400  7 snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
syscopyarea            16384  1 drm_kms_helper
intel_agp              24576  0
sysfillrect            16384  1 drm_kms_helper
eeprom_93cx6           16384  1 rt2800pci
lpc_ich                28672  0
intel_gtt              24576  2 intel_agp,i915
sysimgblt              16384  1 drm_kms_helper
atl1c                  57344  0
rfkill                 28672  4 asus_wmi,cfg80211
fb_sys_fops            16384  1 drm_kms_helper
agpgart                53248  3 intel_agp,intel_gtt,drm
soundcore              16384  1 snd
wmi                    32768  2 asus_wmi,wmi_bmof
evdev                  20480  21
pcc_cpufreq            20480  0
mac_hid                16384  0
acpi_cpufreq           28672  1
battery                24576  0
ac                     16384  0
ip_tables              32768  0
x_tables               49152  1 ip_tables
ext4                  745472  1
crc32c_generic         16384  2
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  131072  1 ext4
fscrypto               32768  1 ext4
sd_mod                 57344  3
serio_raw              20480  0
atkbd                  36864  0
ahci                   40960  2
libps2                 20480  2 atkbd,psmouse
libahci                40960  1 ahci
libata                282624  2 libahci,ahci
uhci_hcd               53248  0
scsi_mod              258048  2 sd_mod,libata
ehci_pci               20480  0
ehci_hcd               98304  1 ehci_pci
i8042                  32768  0
serio                  28672  6 serio_raw,atkbd,psmouse,i8042

kikoloche · 2019-01-06 21:52:54

I have the same problem with an eeePc 1215N since upgrading from linux-lts-4.14 to linux-lts-4.19.

Another issue: when I close the lid, suspension mode doesn't start.

Last edited by kikoloche (2019-01-06 22:03:44)

seth · 2019-01-06 22:03:37

wmi saw some changes between 4.14 and 4.17 (the first claimed occurrence), there seems only one change to asus-wmi in that timeframe.
The idea would be to build a recent kernel with those commits reversed and see whether that fixes things (there's unfortunately no commit labeled "break battery level" ;-)

https://github.com/torvalds/linux/commi … /x86/wmi.c
Commits on Sep 27, 2017 and newer.

Since it's quite some, fetching old linux kernels out of the archive and testing them might save a lot of time.

raffobaffo · 2019-01-22 15:31:18

Upon some experiment I've found out that the last kernel with working battery percentage is 4.16.9-1 from 17 May 2018. After that the kernel 4.17-1 from 4 Jun brings the bug. Can you help me isolate the bad commit?

seth · 2019-01-22 17:21:39

https://wiki.archlinux.org/index.php/Bi … s_with_Git

For a quick test, you can also try to build 4.17 w/ reverted
https://github.com/torvalds/linux/commi … 3bdc77bc4e
and
https://github.com/torvalds/linux/commi … fd0cd0c319
https://github.com/torvalds/linux/commi … fd0cd0c319
though the latter ones should be cosmetical.

skunktrader · 2019-03-03 01:46:19

The ACPI battery state on my eeePC magically started working after updating to 4.20.13.

Perusing the changelog, the only thing that jumps out at me is commit 278b3db146bbdcae9fc7621a34796a43a254d370

Arch Linux

#1 2018-07-19 11:41:36

ACPI wrong battery information

#2 2018-07-19 12:10:33

Re: ACPI wrong battery information

#3 2018-07-19 12:28:44

Re: ACPI wrong battery information

#4 2018-07-19 14:37:13

Re: ACPI wrong battery information

#5 2018-07-20 18:04:59

Re: ACPI wrong battery information

#6 2018-07-20 18:36:11

Re: ACPI wrong battery information

#7 2018-07-31 03:03:42

Re: ACPI wrong battery information

#8 2018-07-31 03:40:30

Re: ACPI wrong battery information

#9 2018-07-31 05:29:40

Re: ACPI wrong battery information

#10 2018-07-31 14:00:28

Re: ACPI wrong battery information

#11 2018-07-31 18:14:29

Re: ACPI wrong battery information

#12 2018-09-02 10:15:01

Re: ACPI wrong battery information

#13 2018-09-02 14:36:59

Re: ACPI wrong battery information

#14 2019-01-03 14:17:42

Re: ACPI wrong battery information

#15 2019-01-03 22:24:31

Re: ACPI wrong battery information

#16 2019-01-04 11:16:22

Re: ACPI wrong battery information

#17 2019-01-04 13:26:57

Re: ACPI wrong battery information

#18 2019-01-05 11:14:54

Re: ACPI wrong battery information

#19 2019-01-06 21:52:54

Re: ACPI wrong battery information

#20 2019-01-06 22:03:37

Re: ACPI wrong battery information

#21 2019-01-22 15:31:18

Re: ACPI wrong battery information

#22 2019-01-22 17:21:39

Re: ACPI wrong battery information

#23 2019-03-03 01:46:19

Re: ACPI wrong battery information

Board footer