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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux