On 25/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> wrote: > Ash Milsted wrote: > > On 25/10/2007, Ash Milsted <thatistosayiseenem@xxxxxxxxx> wrote: > >> On 24/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> wrote: > >>> Ash Milsted wrote: > >>>> On 24/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> 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? > Just tested the stock Archlinux 2.6.23.1 - no discharge uevents *or* (un)plug uevents no matter what I do. Reading the relevant proc file always gives the current state of the battery. Also, back on 2.6.24-rc1, it seems I can provoke a single 'changed' uevent (my printks trigger) after a reboot by reading charge_now a couple of times (it does not seem to occur spontaneously). What happens is that the charge_now value 'jumps' to an apparently odd value (e.g. it increases a little even though AC is unplugged) on the read that triggers the uevent and then settles back to normal on subsequent reads. After that single event I get no response and everything is as before (the function is never called again) - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
