2010/11/24 Fatih Tümen <fthtmn+gen...@gmail.com>: > > On Wed, Nov 24, 2010 at 22:51, Paul Hartman <paul.hartman+gen...@gmail.com> > wrote: >> >> 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. >> > > Usually a BIOS update will do it or a kernel update. You can also try to > disable acpi and see if you can keep it working. > kernel parameters come to mind are acpi=off and pci=noacpi. The first one > completely disables acpi and the latter AFAIR just disables acpi routing for > pci subsystem. Look at kernel-parameters in linux Doc for more > combinations.
Thanks, unfortunately it is an old computer (from 2004), the newest BIOS, which is several years old, breaks suspend (it does not resume from suspend, not even Windows XP works...), so I'm using the penultimate BIOS. It's an Acer Ferrari 3400, back in the time when I bought it, the internet was full of people who have to edit their DSDT on Acer laptops in order to fix it, many people had no battery support at all. I know I used some "magic" kernel parameters at some point, I'm not sure if it was ACPI related, though. I will look into them to see if there's anything new in the past 5 years of kernel development that might help me. :)