Ash Milsted wrote: > On 27/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> 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). - 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
