You are not logged in.
Pages: 1
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
Offline
You might try to compare the two distro settings.
do it good first, it will be faster than do it twice the saint
Offline
I have the identical problem with an eeePc since upgrading to 4.17
Offline
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?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
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?
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)
Offline
Would check if the issue is fixed in 4.18-rc5 first before contacting upstream.
Offline
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?
Offline
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
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
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.
Offline
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=
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
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.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
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.
Offline
* 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.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
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
Offline
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)
Online
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.
Offline
that both ac and battery modules
Please post the actual output, those are generic modules.
Online
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
Offline
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)
Offline
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.
Online
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?
Offline
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.
Online
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
Offline
Pages: 1