| 1 |
2010/11/24 Fatih Tümen <fthtmn+gentoo@×××××.com>: |
| 2 |
> |
| 3 |
> On Wed, Nov 24, 2010 at 22:51, Paul Hartman <paul.hartman+gentoo@×××××.com> |
| 4 |
> wrote: |
| 5 |
>> |
| 6 |
>> On Sun, Nov 21, 2010 at 12:43 AM, Paul Hartman |
| 7 |
>> <paul.hartman+gentoo@×××××.com> wrote: |
| 8 |
>> > On Wed, Nov 17, 2010 at 12:03 AM, Paul Hartman |
| 9 |
>> > <paul.hartman+gentoo@×××××.com> wrote: |
| 10 |
>> >> On Thu, Nov 11, 2010 at 1:11 PM, J. Roeleveld <joost@××××××××.org> |
| 11 |
>> >> wrote: |
| 12 |
>> >>> On Thursday 11 November 2010 18:07:35 Paul Hartman wrote: |
| 13 |
>> >>>> On Wed, Nov 10, 2010 at 12:05 PM, J. Roeleveld <joost@××××××××.org> |
| 14 |
>> >>>> wrote: |
| 15 |
>> >>>> > If the soldering isn't done correctly, the battery-pack can |
| 16 |
>> >>>> > literally |
| 17 |
>> >>>> > explode when put under load. |
| 18 |
>> >>>> |
| 19 |
>> >>>> Yeah, I don't think the savings would be big enough to justify the |
| 20 |
>> >>>> risk. |
| 21 |
>> >>>> |
| 22 |
>> >>>> I found a replacement battery online for less than USD$30 so I |
| 23 |
>> >>>> ordered |
| 24 |
>> >>>> it. Hopefully it fits and holds a charge. :) |
| 25 |
>> >>> |
| 26 |
>> >>> Good luck :) |
| 27 |
>> >>> If laptops would work with the same LIPO-packs that are used for |
| 28 |
>> >>> Remote |
| 29 |
>> >>> Control planes, then it would be cheaper and easier as the chargers |
| 30 |
>> >>> used for |
| 31 |
>> >>> those are better then the stuff they stick in laptops. |
| 32 |
>> >>> |
| 33 |
>> >>> But that's wishfull thinking |
| 34 |
>> >> |
| 35 |
>> >> The replacement battery is good, it fits perfectly and holds over 90% |
| 36 |
>> >> of maximum rated charge. |
| 37 |
>> >> |
| 38 |
>> >> I booted from Sabayon KDE LiveCD and the battery meter works fine in |
| 39 |
>> >> there, so there must be something wrong in my config. I will dig |
| 40 |
>> >> deeper to try to identify the differences. |
| 41 |
>> >> |
| 42 |
>> >> Thanks for all suggestions. :) |
| 43 |
>> > |
| 44 |
>> > After a combination of kernel upgrade, BIOS downgrade (to fix an |
| 45 |
>> > unrelated bug with resuming from suspend), KDE upgrades, and of course |
| 46 |
>> > general "messing with stuff", now it is working most of the time. I |
| 47 |
>> > have an actual battery meter and power management works and I am |
| 48 |
>> > happy. |
| 49 |
>> > |
| 50 |
>> > I sometimes get ACPI/DSDT errors in dmesg from boot time, about |
| 51 |
>> > infinite loops in 3 places, and when this happens the battery is |
| 52 |
>> > either "not present" to ACPI or is present but the state never changes |
| 53 |
>> > (for example remaining capacity at boot time is 2048 and this will |
| 54 |
>> > remain to be the value even as battery is dying). This properly seems |
| 55 |
>> > to happen randomly, or maybe affected somehow by dual-booting into MS |
| 56 |
>> > Windows. I didn't think DSDT/ACPI changes by the OS were persistent? |
| 57 |
>> > Perhaps it's something to do with warm rebooting vs powering off and |
| 58 |
>> > back on. I will have to experiment with it some more to see if I can |
| 59 |
>> > break it :) |
| 60 |
>> > |
| 61 |
>> > A long time ago I tried to extract and repair my broken DSDT but it |
| 62 |
>> > was over my head. I don't understand why it doesn't always work but |
| 63 |
>> > for now things seem to be functioning properly when ACPI is okay at |
| 64 |
>> > boot time. |
| 65 |
>> |
| 66 |
>> Another follow-up. It seems to work normally until it gets this error, |
| 67 |
>> at which point batter monitor stops working. Sometimes this error |
| 68 |
>> happens right away, other times it works for hours and then breaks. I |
| 69 |
>> guess it's a DSDT problem: |
| 70 |
>> |
| 71 |
>> ACPI Error (psparse-0537): Method parse/execution failed |
| 72 |
>> [\_SB_.PCI0.PIB_.EC0_.SMRD] (Node ffff88007f826320), |
| 73 |
>> AE_AML_INFINITE_LOOP |
| 74 |
>> ACPI Error (psparse-0537): Method parse/execution failed |
| 75 |
>> [\_SB_.BAT1.CHBP] (Node ffff88007f81d0f0), AE_AML_INFINITE_LOOP |
| 76 |
>> ACPI Error (psparse-0537): Method parse/execution failed |
| 77 |
>> [\_SB_.PCI0.PIB_.EC0_.SMSL] (Node ffff88007f826398), |
| 78 |
>> AE_AML_INFINITE_LOOP |
| 79 |
>> ACPI Error (psparse-0537): Method parse/execution failed |
| 80 |
>> [\_SB_.PCI0.PIB_.EC0_._Q09] (Node ffff88007f826438), |
| 81 |
>> AE_AML_INFINITE_LOOP |
| 82 |
>> |
| 83 |
>> Does anyone here know about this kind of thing? I am not really sure |
| 84 |
>> what it means. I've decompiled my DSDT but really don't know anything |
| 85 |
>> about how to fix it. Maybe I need to find some ACPI mailing list. |
| 86 |
>> Thanks. |
| 87 |
>> |
| 88 |
> |
| 89 |
> Usually a BIOS update will do it or a kernel update. You can also try to |
| 90 |
> disable acpi and see if you can keep it working. |
| 91 |
> kernel parameters come to mind are acpi=off and pci=noacpi. The first one |
| 92 |
> completely disables acpi and the latter AFAIR just disables acpi routing for |
| 93 |
> pci subsystem. Look at kernel-parameters in linux Doc for more |
| 94 |
> combinations. |
| 95 |
|
| 96 |
Thanks, unfortunately it is an old computer (from 2004), the newest |
| 97 |
BIOS, which is several years old, breaks suspend (it does not resume |
| 98 |
from suspend, not even Windows XP works...), so I'm using the |
| 99 |
penultimate BIOS. It's an Acer Ferrari 3400, back in the time when I |
| 100 |
bought it, the internet was full of people who have to edit their DSDT |
| 101 |
on Acer laptops in order to fix it, many people had no battery support |
| 102 |
at all. |
| 103 |
|
| 104 |
I know I used some "magic" kernel parameters at some point, I'm not |
| 105 |
sure if it was ACPI related, though. I will look into them to see if |
| 106 |
there's anything new in the past 5 years of kernel development that |
| 107 |
might help me. :) |
Archives