Bug 24492

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>