On a Acer Travelmate 2301, the battery status (energy, current, etc.) doesn't get updated, unless events are triggered (e.g. charger disconnection). Example, with charger on, an old reading is reported: testuser@castor:~$ cat /sys/class/power_supply/BAT0/energy_now 1120000 Immediately after, having unplugged the charger in order to trigger an event, sysfs gets updated: testuser@castor:~$ cat /sys/class/power_supply/BAT0/energy_now 13600000
would you please try this patch and see if it helps? https://patchwork.kernel.org/patch/389472/
(In reply to comment #1) I had a try with no success. I can point out two more hints: - in Debian Lenny, with kernel 2.6.26, I have the same problem, but cat'ing /dev/proc/battery/BAT0/status shows the right value and causes also sysfs to update. - in Debian Etch (don't remember kernel version) everything was working fine and battery gauge was updating regularly.
please build the latest upstream kernel, with CONFIG_ACPI_PROCFS_POWER set. does /proc/battery/BAT0/status show the right value and cause sysfs to update?
Compiled vanilla kernel 2.6.36.2 without any patch. Still no regular update of battery gauge, but sysfs gets updated after querying procfs, as already noticed in Lenny. Also HAL gets the updates with some seconds delay. ------ testuser@castor:~$ date; cat /proc/acpi/battery/BAT0/state ven 10 dic 2010, 16.00.26, CET present: yes capacity state: ok charging state: discharging present rate: 15480 mW remaining capacity: 28400 mWh present voltage: 15637 mV testuser@castor:~$ date; cat /sys/class/power_supply/BAT0/energy_now ven 10 dic 2010, 16.00.30, CET 28400000 testuser@castor:~$ date; cat /sys/class/power_supply/BAT0/energy_now ven 10 dic 2010, 16.02.04, CET 28400000 testuser@castor:~$ date; cat /proc/acpi/battery/BAT0/state ven 10 dic 2010, 16.02.06, CET present: yes capacity state: ok charging state: discharging present rate: 15795 mW remaining capacity: 27970 mWh present voltage: 15622 mV testuser@castor:~$ date; cat /sys/class/power_supply/BAT0/energy_now ven 10 dic 2010, 16.02.10, CET 27970000 ------ testuser@castor:~$ lshal -m Start monitoring devicelist: ------------------------------------------------- 16:00:42.033: computer_power_supply_battery_BAT0 property battery.remaining_time = 102240 (0x18f60) 16:00:42.040: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 1000 (0x3e8) 16:00:42.048: computer_power_supply_battery_BAT0 property battery.charge_level.current = 28400 (0x6ef0) 16:00:42.055: computer_power_supply_battery_BAT0 property battery.reporting.current = 28400 (0x6ef0) 16:00:42.056: computer_power_supply_battery_BAT0 property battery.reporting.rate = 1000 (0x3e8) 16:00:42.059: computer_power_supply_battery_BAT0 property battery.voltage.current = 15637 (0x3d15) 16:02:12.014: computer_power_supply_battery_BAT0 property battery.remaining_time = 99892 (0x18634) 16:02:12.021: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 43 (0x2b) 16:02:12.030: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 1008 (0x3f0) 16:02:12.035: computer_power_supply_battery_BAT0 property battery.charge_level.current = 27970 (0x6d42) 16:02:12.038: computer_power_supply_battery_BAT0 property battery.reporting.current = 27970 (0x6d42) 16:02:12.040: computer_power_supply_battery_BAT0 property battery.reporting.rate = 1008 (0x3f0) 16:02:12.042: computer_power_supply_battery_BAT0 property battery.voltage.current = 15622 (0x3d06)
please run acpi_listen on Debian Etch, is there any output after the battery status being freshed?
Just run a test with Debian Etch Live CD, kernel 2.6.18 with sbs module loaded. I can confirm battery gauge in kde gets regular updates and shows correct value. Running acpi_listen, the following line is reported every 60 seconds: battery BAT0 00000080 00000001 The test has also been performed with kde and acpid stopped and the result is the same (just to make sure that they were not polling procfs and thus causing battery update).
sounds like this system is designed to send the OS battery updates every 60 seconds. (we still get them in single user mode?) if this is true, then this is a regression, some time between 2.6.18 and 2.6.32 please attach the standard output from acpidump
In single user mode acpi_listen complains about refused connection (am I missing something?). The regression must be somewhere between 2.6.18 and 2.6.26, because also Lenny has the same symptoms as recent kernels. acpidump output attached.
Created attachment 40092 [details] acpidump output on Acer TM2301
(In reply to comment #8) > In single user mode acpi_listen complains about refused connection (am I > missing something?). > you can just run "cat /proc/acpi/event" to get ACPI events.
Done. I confirm that, even in single user mode, ACPI reports BAT0 events on /proc/acpi/event every 60 seconds when battery is discharging.
(In reply to comment #11) > Done. I confirm that, even in single user mode, ACPI reports BAT0 events on > /proc/acpi/event every 60 seconds when battery is discharging. Obviously this refers to kernel 2.6.18, which works correctly. In the other tested kernels no acpi events are reported.
that's weird. there is no Battery device and surely no Battery events from the acpidump table you attached. could you please make a double check if the correct acpidump is attached please?
That's correct. This laptop uses the "Smart Battery Subsystem" (see section 10.1 of the ACPI Spec.), which is correctly listed in the DSDT as ACPI0002 inside the Smart Battery Host Controller clause (ACPI0001), which in turn is inside the Embedded Controller clause (PNP0C09). Thus it is perfectly correct not to have any "Control Method Battery" (see section 10 of the ACPI spec: "A battery device is required to either have a Smart Battery subsystem or a Control Method Battery interface"). By the way, the Smart Battery Subsystem is supported by the sbs module of the kernel. This is exactly the reason of my frustration (and as I can see from my searches, also a lot of other users of laptops with SBS, especially from Acer, are experiencing the same): after long waiting, Debian Etch with kernel 2.4.18 was supporting correctly the SBS but this support soon became buggy in the next release, with kernel 2.6.26, and so remains today. Something must have happened in between, and since this problem seems to apply only to laptops with SBS I suspect the reason could be found somewhere in sbs.c, sbshc.c or sbshc.h.
Since this bug still has NEEDINFO status, I was wondering if there is actually any further info that I could provide in order to help solve this issue. If so, just let me know.
Actually I just noticed something I didn't spot before: after the low battery led begins blinking, the gnome battery applet starts updating regularly every 30 seconds and also the sysfs power_now value gets updated. In the meanwhile, anyway, acpi_listen remains silent and doesn't report anything. Strange.
(In reply to comment #14) > Debian Etch with kernel 2.4.18 > was supporting correctly the SBS but this support soon became buggy in the > next > release, with kernel 2.6.26, and so remains today. A correction to this: the regression must be somewhere between 2.6.18 (not 2.4.18) and 2.6.26.
Created attachment 62162 [details] add_get_state_in_get_property.patch Please try this patch.
Applying the patch to kernel 2.6.39.1 I get the following error: CC [M] drivers/acpi/sbs.o drivers/acpi/sbs.c: In function ‘acpi_sbs_battery_get_property’: drivers/acpi/sbs.c:199: error: implicit declaration of function ‘acpi_battery_get_state’ drivers/acpi/sbs.c: At top level: drivers/acpi/sbs.c:375: error: static declaration of ‘acpi_battery_get_state’ follows non-static declaration drivers/acpi/sbs.c:199: note: previous implicit declaration of ‘acpi_battery_get_state’ was here make[2]: *** [drivers/acpi/sbs.o] Error 1 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2
Please apply it in the latest upstream kernel.
Created attachment 62242 [details] add_get_state_in_get_property.patch I am so sorry that I have make a stupid mistake. Try this one on the latest upstream kernel.
The patch compiles cleanly on vanilla kernel 3.0.0-rc3, as well as on Debian flavour 2.6.32-5-34. The values in sysfs are regularly updated every 30 seconds and updating stops when the battery is full. I would be grateful if you can confirm that this is intentional. If so, the patch seems to solve the object of the bug. Anyway, rate of discharge seems to be incorrect: lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/uevent POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000 POWER_SUPPLY_VOLTAGE_NOW=15799000 POWER_SUPPLY_CURRENT_NOW=1018000 POWER_SUPPLY_CURRENT_AVG=985000 POWER_SUPPLY_POWER_NOW=1018000 POWER_SUPPLY_POWER_AVG=985000 POWER_SUPPLY_CAPACITY=34 POWER_SUPPLY_ENERGY_FULL_DESIGN=65120000 POWER_SUPPLY_ENERGY_FULL=23290000 POWER_SUPPLY_ENERGY_NOW=22400000 POWER_SUPPLY_TEMP=259 POWER_SUPPLY_MODEL_NAME=01ZA POWER_SUPPLY_MANUFACTURER=Lezinn With a charge W=22.4 Ah, an actual voltage V=15.799 V and a current I=1.018 A, power should be P=V*I=16.083, resulting in an estimated time of discharge T=W/P=1.393 h. As can be seen above, power value is instead equal to current and not multiplied by voltage, thus giving an unrealistic estimated time T=22 h, which is also reported by upower and, in turn, by gnome-power-manager. Do you have any clue about this?
Correction: the main object of the bug is only partially solved. While discharging the values are updated regularly, BUT if during discharge the charger is connected, updating stops and battery is reported as full, even if it is in fact charging. Example: - Battery discharging, regular updates every 30 s: lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status Discharging - At partial discharge, charger is reconnected and battery begins charging (charger led goes on): lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status Full - From this point on, the battery is reported as full (even if it isn't) and no further updates are performed (no new dots on gnome-power-manager). - Reading battery status from procfs performs a single update, but doesn't restore regular updating: lorenzo@castor:~$ cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charging present rate: 5024 mW remaining capacity: 22140 mWh present voltage: 16795 mV lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status Charging
(In reply to comment #22) > With a charge W=22.4 Ah, an actual voltage V=15.799 V and a current I=1.018 > A, > power should be P=V*I=16.083, resulting in an estimated time of discharge > T=W/P=1.393 h. > > As can be seen above, power value is instead equal to current and not > multiplied by voltage, thus giving an unrealistic estimated time T=22 h, > which > is also reported by upower and, in turn, by gnome-power-manager. Please apply the Remove-the-current-files-in-the-sysfs.patch to test the problem again. Compile the sbs driver as a module. When the problem happens, reload the driver and check whether the value will be corrected. > lorenzo@castor:~$ cat /proc/acpi/battery/BAT0/state > present: yes > capacity state: ok > charging state: charging > present rate: 5024 mW > remaining capacity: 22140 mWh > present voltage: 16795 mV > lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status > Charging This output looks like correct. Did they change correct after reading battery status from procfs? (In reply to comment #23) > Correction: the main object of the bug is only partially solved. > > While discharging the values are updated regularly, BUT if during discharge > the > charger is connected, updating stops and battery is reported as full, even if > it is in fact charging. This looks very strange. I add the message in the patch. When reading the battery status from sysfs, it will produce a message after getting state from the battery. Attach the output of dmesg when the problem happens.
Created attachment 63072 [details] Remove-the-current-files-in-the-sysfs.patch
Created attachment 63112 [details] Remove-the-current-files-in-the-sysfs.patch
The secon version of the Revome-etcetc.patch was applied to kernel 3.0.0-rc3. The previous patch (add_get_etcetc.patch) was not applied since I noticed it is included in the new one. Attached comes the output of dmesg. Below I describe the steps I used to reproduce the bug; each command is timed using /proc/uptime, for easier reference to the dmesg output. - Battery is discharging at boot. Discharging state is indicated correctly in sysfs: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status 395.77 280.46 Discharging - Anyway, the rate of discharge in sysfs is wrong (seems to be current multiplied by 1 instead of voltage), while in procfs it makes sense; reading the procfs doesn't cause the sysfs to change its rate value to the correct one. lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/power_now; cat /proc/acpi/battery/BAT0/state 655.94 528.29 1024000 present: yes capacity state: ok charging state: discharging present rate: 15360 mW remaining capacity: 18600 mWh present voltage: 15636 mV lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/power_now 663.71 535.88 1041000 - Reloading the SBS module doesn't correct the problem: lorenzo@castor:~$ cat /proc/uptime; sudo rmmod sbs 831.79 695.63 [sudo] password for lorenzo: lorenzo@castor:~$ cat /proc/uptime; sudo modprobe sbs 861.92 724.80 lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/power_now 881.26 743.19 1046000 - At t=1028 the charger is connected and the charging led goes on; this is not detected by the kernel, which instead reports the battery as full: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status 1010.63 866.60 Discharging lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status 1037.76 893.13 Full - Differently from what I reported previously, now sysfs updates the value of charge regularly, but apparently the fact that the battery is wrongly indicated as full prevents upower and gnome-power-manager to catch the updates; after some time the sysfs reports again "charging" but mysteriously enough upower doesn't notice the change and monitoring upower waits forever without any updates: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status; upower --monitor-detail 1749.73 1568.61 Charging Monitoring activity from the power daemon. Press Ctrl+C to cancel.
Created attachment 63152 [details] dmesg output related to comments on June 22nd 2011
Created attachment 63262 [details] correct-sysfs-battery-power-now.patch Please try this patch.
(In reply to comment #27) > - Differently from what I reported previously, now sysfs updates the value of > charge regularly, but apparently the fact that the battery is wrongly > indicated > as full prevents upower and gnome-power-manager to catch the updates; after > some time the sysfs reports again "charging" but mysteriously enough upower > doesn't notice the change and monitoring upower waits forever without any > updates: > Please run "cat /proc/uptime; cat /sys/class/power_supply/BAT0/status; cat /proc/acpi/battery/BAT0/status" when replugging the charger and attach the output. I think “upower --monitor-detail” should run before plugging the charger.
New test with your latest patch. dmesg attached. - Battery is discharging at boot. upower --monitor-detail running in background. upower gets regular updates every 30 s, but it indicates "energy-rate: 0 W", so it doesn't provide any estimate for discharge time. Status and rate of discharge is sysfs appear to be correct and coherent with procfs: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status; cat /sys/class/power_supply/BAT0/power_now; cat /proc/acpi/battery/BAT0/state 897.25 714.53 Discharging 15285000 present: yes capacity state: ok charging state: discharging present rate: 15285 mW remaining capacity: 18660 mWh present voltage: 15507 mV - At t=1012 the charger is connected and the charging led goes on; this time the battery is correctly reported as charging: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status; cat /proc/acpi/battery/BAT0/state 1101.55 905.46 Charging present: yes capacity state: ok charging state: charging present rate: 16224 mW remaining capacity: 18510 mWh present voltage: 16707 mV ...but upower is still wrong and reports "fully charged" and still zero rate; also, it stops receiving any more updates: [09:44:52.906] device changed: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:0a/PNP0C09:00/ACPI0001:00/ACPI0002:00/power_supply/BAT0 vendor: Lezinn model: 01ZA power supply: yes updated: Fri Jun 24 09:44:52 2011 (0 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: fully-charged energy: 18.14 Wh energy-empty: 0 Wh energy-full: 23.29 Wh energy-full-design: 65.12 Wh energy-rate: 0 W voltage: 15.97 V percentage: 77.8875% capacity: 35.7647% technology: lithium-ion History (charge): 1308901487 77.888 fully-charged 1308901460 78.317 discharging 1308901430 78.918 discharging 1308901400 79.519 discharging - In the meanwhile, sysfs continues to get updated: lorenzo@castor:~$ cat /proc/uptime; cat /sys/class/power_supply/BAT0/status; cat /sys/class/power_supply/BAT0/power_now; cat /proc/acpi/battery/BAT0/state 1390.74 1170.10 Charging 11376000 present: yes capacity state: ok charging state: charging present rate: 11376 mW remaining capacity: 19500 mWh present voltage: 16750 mV Conclusions: - rate and detection of charging by sysfs seem to be correct; - something prevents upower from getting the right power value; - something prevents upower from getting updates after charger connection.
Created attachment 63412 [details] dmesg output related to comments on June 24th 2011
You can run "acpi_listen & upower --monitor-detail" to check whether the acpi event triggers or not. Did "energy-rate: 0 W" happen without the test patch before? please attach the output "cat /sys/class/power_supply/*/* && cat /proc/acpi/battery/*/*" with the test patch.
(In reply to comment #33) > You can run "acpi_listen & upower --monitor-detail" to check whether the acpi > event triggers or not. acpi_listen doesn't show anything at all from BAT0, even when upower is updating correctly (i.e. when discharging). The only events that acpi_listen gets is charger connection/disconnection (i.e. ac_adapter AC0 00000080 00000001) > Did "energy-rate: 0 W" happen without the test patch before? No: before this patch energy-rate used to be the same value as current_now, and the same was reported in power_now. Now power_now seems to be correct, while upower has zero rate. > please attach the output "cat /sys/class/power_supply/*/* && cat > /proc/acpi/battery/*/*" with the test patch. lorenzo@castor:~$ cat /sys/class/power_supply/*/* && cat /proc/acpi/battery/*/* 0 35 cat: /sys/class/power_supply/BAT0/device: Is a directory 23290000 65120000 22490000 Lezinn 01ZA cat: /sys/class/power_supply/BAT0/power: Is a directory 17680000 15648000 1 Discharging cat: /sys/class/power_supply/BAT0/subsystem: Is a directory Li-ion 341 Battery POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000 POWER_SUPPLY_VOLTAGE_NOW=16028000 POWER_SUPPLY_POWER_NOW=15648000 POWER_SUPPLY_POWER_AVG=17680000 POWER_SUPPLY_CAPACITY=35 POWER_SUPPLY_ENERGY_FULL_DESIGN=65120000 POWER_SUPPLY_ENERGY_FULL=23290000 POWER_SUPPLY_ENERGY_NOW=22490000 POWER_SUPPLY_TEMP=341 POWER_SUPPLY_MODEL_NAME=01ZA POWER_SUPPLY_MANUFACTURER=Lezinn 14800000 16028000 cat: /sys/class/power_supply/sbs-charger/device: Is a directory 0 cat: /sys/class/power_supply/sbs-charger/power: Is a directory cat: /sys/class/power_supply/sbs-charger/subsystem: Is a directory Mains POWER_SUPPLY_NAME=sbs-charger POWER_SUPPLY_ONLINE=0
Created attachment 63542 [details] correct-sysfs-battery-power-now.patch Please try this patch.
Tried also the latest patch. The issue with incorrect power value seems to be solved, anyway is is still not updating after charger reconnection. Here below are some of the tests performed. - Battery discharging, power_now value makes sense, upower updates regularly and shows a reasonable time estimate for discharge: lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status; cat /sys/class/power_supply/BAT0/power_now Discharging 14460000 - As soon as the charger is reconnected, AC power is detected correctly. upower reports "state: fully-charged", but from this time on it stops getting updates. Please note that at this stage the charger led is still off, as the charger logic seems to have some delay before starting the charge. lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status; cat /sys/class/power_supply/BAT0/power_now Full 0 - After some seconds the charger led goes on, but upower doesn't get any updates so it continues to report "state: fully-charged" and "energy-rate: 0 W", while energy value doesn't change. In the meanwhile sysfs reports correctly the charging status and rate: lorenzo@castor:~$ cat /sys/class/power_supply/BAT0/status; cat /sys/class/power_supply/BAT0/power_now Charging 8688000
Current the sysfs works correctly. If upower queried power_now, it would get correct status. But it didn't. I guess it maybe a upower issue. Do you use the latest version? I use the 0.9.1 version and test it on my laptop. But it's battery is not sbs. Do the same operation. "energy-rate: 0W" will also happen sometime while the sysfs power_now is correct. But after 30 seconds, upower updated data correctly. (In reply to comment #31) >- Battery is discharging at boot. upower --monitor-detail running in >background. upower gets regular updates every 30 s, but it indicates >"energy-rate: 0 W", so it doesn't provide any estimate for discharge time. >Status and rate of discharge is sysfs appear to be correct and coherent with >procfs: (In reply to comment #34) > > Did "energy-rate: 0 W" happen without the test patch before? > No: before this patch energy-rate used to be the same value as current_now, > and > the same was reported in power_now. Now power_now seems to be correct, while > upower has zero rate. I find the upower depend on the "/sys/class/power_supply/BAT0/current_now". In the patch https://bugzilla.kernel.org/attachment.cgi?id=63262, I remove the current_now and current_avg from the sysfs when the battery unit is "mW". The current_now and current_avg should not be exist at that time. But this caused the "energy-rate: 0 W". The upower work abnormally. Hi Matthew Garrett, I find you removed the current_now in the battery.c when the unit is "mW". Commit b137b9942a07843c64a934cfdb7d43155e507e13. Have you seen such problem? Thanks.
I use upower version 0.9.5 (stock debian stable package). I don't think it actually depends on current_now, since the patch removed it and and still the rate is correct. Seems that upower (at least in the version I use) gets the rate information directly from power_now, since once the value was corrected in sysfs upower began to report the correct rate. The problem, from my point of view, is: what triggers upower to read status and rate from sysfs every 30 s during discharge? And what causes it to stop triggering after charger reconnection? Is it something inside the kernel or something inside upower? If it could continue to update, it would notice the state change from full to charging. By the way, thanks much for your help and sorry if I can contribute only with testing and reporting.
https://bugzilla.kernel.org/attachment.cgi?id=63262 (In comment #29) This patch removed the current_now and current_avg when the unit is "mW". (In comment #34) > > Did "energy-rate: 0 W" happen without the test patch before? > No: before this patch energy-rate used to be the same value as current_now, > and the same was reported in power_now. Now power_now seems to be correct, > while upower has zero rate. From this response, I guess the upower depend on the current_now or current_avg https://bugzilla.kernel.org/attachment.cgi?id=63542(In comment #35) This is the latest path which remains the current_now and current_avg. (In comment #36) >Tried also the latest patch. The issue with incorrect power value seems to be >solved, anyway is is still not updating after charger reconnection. Here below >are some of the tests performed. From your reply, I confirmed. (In reply to comment #38) > The problem, from my point of view, is: what triggers upower to read status > and rate from sysfs every 30 s during discharge? And what causes it to stop > triggering after charger reconnection? Is it something inside the kernel or > something inside upower? If it could continue to update, it would notice the > state change from full to charging. I am sorry that I'm not familiar with how upower works. I think you can try the higher version. The read status and rate every 30s is a regular operation. But why it stopped during the reconnection. I am not clear. I think you have done a good job. Thanks for your support.
Now, kernel works with patches correctly. So close the bug. It currently looks like upower issue. If have some suspicion, welcome to reopen. https://patchwork.kernel.org/patch/934782/ https://patchwork.kernel.org/patch/934792/
patches noted in comment #40 applied to acpi-test tree
pulled into linux-3.1 merge window. closed. commit e4108292cc5b5ca07abc83af31a78338362810ca Author: Lan Tianyu <tianyu.lan@intel.com> Date: Fri Jul 1 16:03:39 2011 +0800 ACPI / SBS: Correct the value of power_now and power_avg in the sysfs https://bugzilla.kernel.org/show_bug.cgi?id=24492 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> commit 1dd5c715e5b7524da8c1030f5cf1ea903e45c457 Author: Lan Tianyu <tianyu.lan@intel.com> Date: Fri Jul 1 16:03:15 2011 +0800 ACPI / SBS: Add getting state operation in the acpi_sbs_battery_get_property https://bugzilla.kernel.org/show_bug.cgi?id=24492 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>