Re: [SOLVED] Re: battery state - hw.acpi.battery.life goes only down
On Wed, 26 Sep 2012 02:24:14 +0200, Michael Schuh wrote: sorry for the buzz... 2012/9/26 Brandon Allbery allber...@gmail.com On Tue, Sep 25, 2012 at 8:10 PM, Michael Schuh michael.sc...@gmail.comwrote: hmm, may be. i didn't thinked about that lithium charging feature. you may right with that. Yes you are right with that point. I have watched batteries cycle like that on OS X, Linux, and FreeBSD, and some versions of Windows; possibly more recent versions try to hide it. It's also possible the ACPI BIOS normally hides it but needs some recalibration step (on Macs, for example, you need to fully charge then fully discharge then fully charge again to recalibrate it; I think that's common). Yesi agree, this is the most logic explanation in our fantastic world. Just to confirm what Brandon said, I've watched this behaviour for some years on a couple of IBM Thinkpad T23s .. while on AC power the battery slowly self-discharges down to about 95% before a charge cycle begins to boost it back to 100%. Mine is now sitting at 98% and will take days to get down to 95% and start charging again, if I don't run it on battery. but one point, this behaviour is new. i made some tests to check if my conkyrc is right and there i haven't wait that the battery is gone under 90% for checking this. after i could confirm that the conkyrc is syntactically correct, the battery reached 100% again. That sounds like it is normal cycling then. No idea why that box didn't showed that behaviour earlier. i am fully sure that i made the same tests before and the charger did jump in much time earlier. may be, i was a bit impatient for now. May depend on your workload; I don't know conkyrc but use gkrellm to show battery state, before that I more often ran acpiconf -i0 to check state, which also shows such as Last Full Capacity vs Design Capacity, for some indication of how well your battery is holding up over time. Lithium-Ion batteries really should be cycled semi-regularly anyway; as Brandon also mentioned, the occasional complete discharge down to (or beyond!) exhaustion (safely done at the BIOS setup screen) followed by a full recharge is often recommended to fully recalibrate the battery's internal Coulomb Counter, ie the battery's own idea of its percentage capacity, reported to ACPI typically via the EC (embedded controller). This is likely more on-topic (and welcome) on freebsd-mobile@ though, unless of course some regression in system software is suspected .. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state - hw.acpi.battery.life goes only down
On Tue, Sep 25, 2012 at 7:43 PM, Michael Schuh michael.sc...@gmail.comwrote: this wrong number seems persistent during a reboot. i tested this, shortly. the battery life after reboot was 97% with power supply plugged in all the times. after a clean boot the system camed up with a battery.life of 97% ( power supply plugged in :O ). Sounds like normal lithium ion charger behavior to me; typically they won't kick in the charger until it reaches somewhere between 90-95% (depends on the device). This extends the useful life of the battery; raw lithium ion is just as (actually, more) prone to destruction via overcharging as other battery technologies. http://batteryuniversity.com/learn/article/charging_lithium_ion_batteriesdiscusses this. Note in particular: A continuous trickle charge would cause plating of metallic lithium, and this could compromise safety. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state - hw.acpi.battery.life goes only down
2012/9/26 Brandon Allbery allber...@gmail.com On Tue, Sep 25, 2012 at 7:43 PM, Michael Schuh michael.sc...@gmail.comwrote: this wrong number seems persistent during a reboot. i tested this, shortly. the battery life after reboot was 97% with power supply plugged in all the times. after a clean boot the system camed up with a battery.life of 97% ( power supply plugged in :O ). Sounds like normal lithium ion charger behavior to me; typically they won't kick in the charger until it reaches somewhere between 90-95% (depends on the device). This extends the useful life of the battery; raw lithium ion is just as (actually, more) prone to destruction via overcharging as other battery technologies. http://batteryuniversity.com/learn/article/charging_lithium_ion_batteriesdiscusses this. Note in particular: A continuous trickle charge would cause plating of metallic lithium, and this could compromise safety. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms hmm, may be. i didn't thinked about that lithium charging feature. you may right with that. but one point, this behaviour is new. i made some tests to check if my conkyrc is right and there i haven't wait that the battery is gone under 90% for checking this. after i could confirm that the conkyrc is syntactically correct, the battery reached 100% again. that was before i updated the system last week. i will check that out. under the load of a make world it should only take minutes to get the battery.life under 80%. many thanks for your hint. -- = = = http://michael-schuh.net/ = = = Projektmanagement - IT-Consulting - Professional Services IT Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0175/5616453 @: m i c h a e l . s c h u h @ g m a i l . c o m = = = Ust-ID: DE251072318 = = = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state - hw.acpi.battery.life goes only down
On Tue, Sep 25, 2012 at 8:10 PM, Michael Schuh michael.sc...@gmail.comwrote: hmm, may be. i didn't thinked about that lithium charging feature. you may right with that. I have watched batteries cycle like that on OS X, Linux, and FreeBSD, and some versions of Windows; possibly more recent versions try to hide it. It's also possible the ACPI BIOS normally hides it but needs some recalibration step (on Macs, for example, you need to fully charge then fully discharge then fully charge again to recalibrate it; I think that's common). but one point, this behaviour is new. i made some tests to check if my conkyrc is right and there i haven't wait that the battery is gone under 90% for checking this. after i could confirm that the conkyrc is syntactically correct, the battery reached 100% again. That sounds like it is normal cycling then. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[SOLVED] Re: battery state - hw.acpi.battery.life goes only down
sorry for the buzz... 2012/9/26 Brandon Allbery allber...@gmail.com On Tue, Sep 25, 2012 at 8:10 PM, Michael Schuh michael.sc...@gmail.comwrote: hmm, may be. i didn't thinked about that lithium charging feature. you may right with that. Yes you are right with that point. I have watched batteries cycle like that on OS X, Linux, and FreeBSD, and some versions of Windows; possibly more recent versions try to hide it. It's also possible the ACPI BIOS normally hides it but needs some recalibration step (on Macs, for example, you need to fully charge then fully discharge then fully charge again to recalibrate it; I think that's common). Yesi agree, this is the most logic explanation in our fantastic world. but one point, this behaviour is new. i made some tests to check if my conkyrc is right and there i haven't wait that the battery is gone under 90% for checking this. after i could confirm that the conkyrc is syntactically correct, the battery reached 100% again. That sounds like it is normal cycling then. No idea why that box didn't showed that behaviour earlier. i am fully sure that i made the same tests before and the charger did jump in much time earlier. may be, i was a bit impatient for now. many thanks again. cheers m. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -- = = = http://michael-schuh.net/ = = = Projektmanagement - IT-Consulting - Professional Services IT Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0175/5616453 @: m i c h a e l . s c h u h @ g m a i l . c o m = = = Ust-ID: DE251072318 = = = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 16/08/2012 07:39, Ian Smith wrote: On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: ... I found your correspondence here last December about that, Re: battery display broken. Looks like it's still the same problem, you were on 9-stable then too. When did it used to work? Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had worked then, or I'd have PRed a regression. It stopped working around the beginning of this FSAE season. Probably between September and December. On either normal or verbose boot messages, are there any ACPI errors logged? This smells a bit like some of the Embedded Controller issues that were coming up late 2010, most resolved by some patches by avg@. This is from the verbose dmesg: # dmesg | grep -i bat battery0: ACPI Control Method Battery on acpi0 battery1: ACPI Control Method Battery on acpi0 battery0: battery initialization start battery1: battery initialization start battery0: battery initialization done, tried 1 times battery1: battery initialization failed, giving up Looks right to me. Greping for acpi or fail doesn't yield anything interesting. There is a bunch of errors during shutdown, I have a dmesg with verbose boot, shutdown and normal boot prepared, for whoever wants to look at it. Someone then worked around some EC issue using debug.acpi.ec.polled mode rather than relying on notifications, I vaguely recall. You said then you run only one battery, so hw.acpi.battery.units is also still wrong? Yes, it's wrong. There is an option to swap out the optical drive for a battery, I think. But I still have my optical drive. Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 shortly before a 10.0 release. If there's any indication of ACPI errors on boot (or later) this would be worthy of a PR, especially as you're not alone in this, on HP gear. I suppose you've checked HP for any more recent BIOS /or EC updates? The bios version reported by dmidecode matches the latest download from HP: Vendor: Hewlett-Packard Version: 68DDU Ver. F.15 Release Date: 01/15/2009 Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On Thu, 16 Aug 2012 10:24:46 +0200, Dominic Fandrey wrote: On 16/08/2012 07:39, Ian Smith wrote: On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: ... I found your correspondence here last December about that, Re: battery display broken. Looks like it's still the same problem, you were on 9-stable then too. When did it used to work? Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had worked then, or I'd have PRed a regression. I was referring to this thread, which I then also had a stab at: http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064953.html It stopped working around the beginning of this FSAE season. Probably between September and December. On either normal or verbose boot messages, are there any ACPI errors logged? This smells a bit like some of the Embedded Controller issues that were coming up late 2010, most resolved by some patches by avg@. This is from the verbose dmesg: # dmesg | grep -i bat battery0: ACPI Control Method Battery on acpi0 battery1: ACPI Control Method Battery on acpi0 battery0: battery initialization start battery1: battery initialization start battery0: battery initialization done, tried 1 times battery1: battery initialization failed, giving up Looks right to me. Greping for acpi or fail doesn't yield anything interesting. Ok. Several others reported things like: ACPI Error: Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc43284e0), AE_NO_HARDWARE_RESPONSE (20100915/psparse-633) acpi_ec0: EcRead: failed waiting to get data See also kern/162859 mentioned in the above thread, which seems similar. There is a bunch of errors during shutdown, I have a dmesg with verbose boot, shutdown and normal boot prepared, for whoever wants to look at it. If you take it any further, that might be handy .. Someone then worked around some EC issue using debug.acpi.ec.polled mode rather than relying on notifications, I vaguely recall. You said then you run only one battery, so hw.acpi.battery.units is also still wrong? Yes, it's wrong. There is an option to swap out the optical drive for a battery, I think. But I still have my optical drive. Just more grist for the mill. My Thinkpad also can take another battery in the optical drive bay, but only shows one battery unless it's fitted. Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 shortly before a 10.0 release. If there's any indication of ACPI errors on boot (or later) this would be worthy of a PR, especially as you're not alone in this, on HP gear. I suppose you've checked HP for any more recent BIOS /or EC updates? The bios version reported by dmidecode matches the latest download from HP: Vendor: Hewlett-Packard Version: 68DDU Ver. F.15 Release Date: 01/15/2009 Ah well, it was woth a shot :) cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 16/08/2012 12:41, Ian Smith wrote: On Thu, 16 Aug 2012 10:24:46 +0200, Dominic Fandrey wrote: On 16/08/2012 07:39, Ian Smith wrote: On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: ... I found your correspondence here last December about that, Re: battery display broken. Looks like it's still the same problem, you were on 9-stable then too. When did it used to work? Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had worked then, or I'd have PRed a regression. I was referring to this thread, which I then also had a stab at: http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064953.html That never progressed to a technical level so it only suffices to reduce the time frame. I don't remember any more. I know I'm made this more difficult by not having written a PR right when it happened. I appologize for this. I don't see what I can do to mitigate it, though. It stopped working around the beginning of this FSAE season. Probably between September and December. On either normal or verbose boot messages, are there any ACPI errors logged? This smells a bit like some of the Embedded Controller issues that were coming up late 2010, most resolved by some patches by avg@. This is from the verbose dmesg: # dmesg | grep -i bat battery0: ACPI Control Method Battery on acpi0 battery1: ACPI Control Method Battery on acpi0 battery0: battery initialization start battery1: battery initialization start battery0: battery initialization done, tried 1 times battery1: battery initialization failed, giving up Looks right to me. Greping for acpi or fail doesn't yield anything interesting. Ok. Several others reported things like: ACPI Error: Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc43284e0), AE_NO_HARDWARE_RESPONSE (20100915/psparse-633) acpi_ec0: EcRead: failed waiting to get data Nothing like this occurs. See also kern/162859 mentioned in the above thread, which seems similar. It looks like it's exactly my problem. There is a bunch of errors during shutdown, I have a dmesg with verbose boot, shutdown and normal boot prepared, for whoever wants to look at it. If you take it any further, that might be handy .. I just sent the dmesg to kern/162859. Someone then worked around some EC issue using debug.acpi.ec.polled mode rather than relying on notifications, I vaguely recall. ... I also tried that. It works exactly once. I.e. the system polls one new battery state. Which then becomes permanent. Turning it off and on repeatedly doesn't win me new states. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.dewrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. snip It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Best regards Andreas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.dewrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. snip It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey kamik...@bsdforen.dewrote: On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.de wrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. snip It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. Also hw.acpi.battery.state=0 for me equals AC plugged in and battery full. I have this in my .xinitrc to monitor my battery ( in a loop which then uses xsetroot to show the info ): case `sysctl -n hw.acpi.battery.state` in 0) batstate=AC full ;; 1) batstate=`sysctl -n hw.acpi.battery.time` m ;; 2) batstate=AC charing ;; Best regards Andreas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 2012-08-15 11:07, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey kamik...@bsdforen.dewrote: On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.de wrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. Also hw.acpi.battery.state=0 for me equals AC plugged in and battery full. Just a short aol. I'm seeing the same issue, also on a HP laptop, a HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact model). It has been this way for as long as I can remember (at least a year), but I haven't checked into the matter more closely. Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Regards! -- Niclas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 15/08/2012 11:16, Niclas Zeising wrote: On 2012-08-15 11:07, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey kamik...@bsdforen.dewrote: On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.de wrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. Also hw.acpi.battery.state=0 for me equals AC plugged in and battery full. Just a short aol. I'm seeing the same issue, also on a HP laptop, a HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact model). It has been this way for as long as I can remember (at least a year), but I haven't checked into the matter more closely. There was a time when this actually worked for me. I should have reacted instantly when the problem came up, but I had a race car to build ... FSAE. Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 shortly before a 10.0 release. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On 15/08/2012 11:07, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey kamik...@bsdforen.dewrote: On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.de wrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. snip It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. You can tune this with hw.acpi.battery.info_expire. But 5 seconds sounds like an OKish value to me. Also hw.acpi.battery.state=0 for me equals AC plugged in and battery full. That was the correct state while the system was booting. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: battery state
On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: On 15/08/2012 11:16, Niclas Zeising wrote: On 2012-08-15 11:07, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey kamik...@bsdforen.dewrote: On 15/08/2012 10:40, Andreas Nilsson wrote: On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey kamik...@bsdforen.de wrote: For a while now acpiconf -i0 always shows the battery state that was correct when booting the system. It's never updated. It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. Also hw.acpi.battery.state=0 for me equals AC plugged in and battery full. Just a short aol. I'm seeing the same issue, also on a HP laptop, a HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact model). It has been this way for as long as I can remember (at least a year), but I haven't checked into the matter more closely. There was a time when this actually worked for me. I should have reacted instantly when the problem came up, but I had a race car to build ... FSAE. I found your correspondence here last December about that, Re: battery display broken. Looks like it's still the same problem, you were on 9-stable then too. When did it used to work? On either normal or verbose boot messages, are there any ACPI errors logged? This smells a bit like some of the Embedded Controller issues that were coming up late 2010, most resolved by some patches by avg@. Someone then worked around some EC issue using debug.acpi.ec.polled mode rather than relying on notifications, I vaguely recall. You said then you run only one battery, so hw.acpi.battery.units is also still wrong? Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 shortly before a 10.0 release. If there's any indication of ACPI errors on boot (or later) this would be worthy of a PR, especially as you're not alone in this, on HP gear. I suppose you've checked HP for any more recent BIOS /or EC updates? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
