On Sun, Nov 21, 2010 at 12:43 AM, Paul Hartman <paul.hartman+gen...@gmail.com> wrote: > On Wed, Nov 17, 2010 at 12:03 AM, Paul Hartman > <paul.hartman+gen...@gmail.com> wrote: >> On Thu, Nov 11, 2010 at 1:11 PM, J. Roeleveld <jo...@antarean.org> wrote: >>> On Thursday 11 November 2010 18:07:35 Paul Hartman wrote: >>>> On Wed, Nov 10, 2010 at 12:05 PM, J. Roeleveld <jo...@antarean.org> wrote: >>>> > If the soldering isn't done correctly, the battery-pack can literally >>>> > explode when put under load. >>>> >>>> Yeah, I don't think the savings would be big enough to justify the risk. >>>> >>>> I found a replacement battery online for less than USD$30 so I ordered >>>> it. Hopefully it fits and holds a charge. :) >>> >>> Good luck :) >>> If laptops would work with the same LIPO-packs that are used for Remote >>> Control planes, then it would be cheaper and easier as the chargers used for >>> those are better then the stuff they stick in laptops. >>> >>> But that's wishfull thinking >> >> The replacement battery is good, it fits perfectly and holds over 90% >> of maximum rated charge. >> >> I booted from Sabayon KDE LiveCD and the battery meter works fine in >> there, so there must be something wrong in my config. I will dig >> deeper to try to identify the differences. >> >> Thanks for all suggestions. :) > > After a combination of kernel upgrade, BIOS downgrade (to fix an > unrelated bug with resuming from suspend), KDE upgrades, and of course > general "messing with stuff", now it is working most of the time. I > have an actual battery meter and power management works and I am > happy. > > I sometimes get ACPI/DSDT errors in dmesg from boot time, about > infinite loops in 3 places, and when this happens the battery is > either "not present" to ACPI or is present but the state never changes > (for example remaining capacity at boot time is 2048 and this will > remain to be the value even as battery is dying). This properly seems > to happen randomly, or maybe affected somehow by dual-booting into MS > Windows. I didn't think DSDT/ACPI changes by the OS were persistent? > Perhaps it's something to do with warm rebooting vs powering off and > back on. I will have to experiment with it some more to see if I can > break it :) > > A long time ago I tried to extract and repair my broken DSDT but it > was over my head. I don't understand why it doesn't always work but > for now things seem to be functioning properly when ACPI is okay at > boot time.
Another follow-up. It seems to work normally until it gets this error, at which point batter monitor stops working. Sometimes this error happens right away, other times it works for hours and then breaks. I guess it's a DSDT problem: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PIB_.EC0_.SMRD] (Node ffff88007f826320), AE_AML_INFINITE_LOOP ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.BAT1.CHBP] (Node ffff88007f81d0f0), AE_AML_INFINITE_LOOP ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PIB_.EC0_.SMSL] (Node ffff88007f826398), AE_AML_INFINITE_LOOP ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PIB_.EC0_._Q09] (Node ffff88007f826438), AE_AML_INFINITE_LOOP Does anyone here know about this kind of thing? I am not really sure what it means. I've decompiled my DSDT but really don't know anything about how to fix it. Maybe I need to find some ACPI mailing list. Thanks.
