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

[Alexey Starikovskiy <aystarik@gmail.com>]

Ash Milsted wrote:
> On 25/10/2007, Ash Milsted <thatistosayiseenem@gawab.com> wrote:
>> On 24/10/2007, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>>> Ash Milsted wrote:
>>>> On 24/10/2007, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>>>>> This one is not easy. According to code, it should send twice as many notifications now.
>>>>> One over netlink, and one as power_supply class device...
>>>>> Could you log all the uevents?
>>>>>
>>>> Forgive my ignorance, but I'm not entirely sure how to capture
>>>> uevents. If "udevmonitor --kernel" is sufficient then it appears there
>>>> are no events associated with the battery discharging or charging,
>>>> whereas those associated with (un)plugging do appear. To clarify, I've
>>>> seen cat /sys/.../charge_now change without udevmonitor picking up a
>>>> single kernel event.
>>> Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c?
>>> This is the only place which could send uevent. If you don't see this printk in
>>> dmesg, then HAL uses some other method to get battery state changes.
>>>
>> I can confirm that this function is *not* called as the battery
>> (dis)charges (having seen charge_now fall), but is called on
>> power-plug events.
> Sorry... I mean it appears to be called on module-insertion and then
> *never* again (not on plug events).
> 
Could you please confirm, that there were no battery discharge uevents before, e.g in 2.6.23?