Re: 2.6.24-rc1 acpi battery driver -> sysfs interface does not update correctly

[Alexey Starikovskiy <aystarik@gmail.com>]

Ash Milsted wrote:
> On 27/10/2007, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>> Ash Milsted wrote:
>>> Hi again,
>>> I just thought I'd say that this is still occuring with the current
>>> linux-acpi-2.6 git tree on top of Linus' latest.. I don't get
>>> (dis)charge uevents and, oddly, the sysfs charge_now value is
>> As I remember, you did not found uevents in 2.6.23 as well?
> 
> Yeah, no uevents for (dis)charges or (un)plugs in 2.6.23.
> 
>>> initially wrong on boot-up. For some reason it gives a value of about
>>> half the full charge of the battery (no matter what the true value is)
>>> until I read it a couple of times, at which point it corrects itself.
> 
> Reading the sysfs value is, it turns out, not necessary to trigger
> this single update (which also sends a change uevent). I guess this is
> just the battery driver grabbing the initial value - after that there
> are no more change uevents.
> 
>>> I attach a few extra details, in case they help.
>> your acpidump output might be usefull at this point.
> 
> Attached.
> 
Ok, it seems to be related with ECDY variable of your DSDT.
It is equal to 5 by default, but could be set to 0 or 3 if _OS string matches 
some magic length (guess Linux does not match).
BST (method for reading state out of memory) may send notify event if ECDY 
is 1 (it will become this only uevent you see at very start).
I do not see how battery driver could help in this situation.
What you could do is try to play with acpi_os variable so that ECDY becomes 0.
You also could patch your DSDT to have ECDY=0 always (or try to update BIOS, it might be done already).