On 28/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: > 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). >
I see. I'll see what I can do to get that fixed, although I think I'm using the latest bios for this machine. I guess I'll play with the acpi_os value. I wonder how common this problem is. This laptop is quite old (Toshiba Satellite 1110), but if this is a common issue I guess it makes sense for either HAL or the battery driver to poll in certain cases (e.g. poll if we haven't been receiving events/interrupts but we should be charging/discharging or, if it ain't common, this could be a HAL 'quirk'). As long as users of the uevent interface are aware of this possible issue I guess they could be responsible for polling - do you think I should let the HAL guys know? Ash - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
