battery state

[Oliver Pinter]

On 8/16/12, Dominic Fandrey <kamikaze at bsdforen.de> wrote:
> 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 at .
>>   >
>>   > 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
>

Hi!

If the problem still occurs, then try to add "options ACPI_DEBUG" to
kernel config, and recompile the kernel. In my case, this fixed this
"dead" battery status on HP Probook 430.

>
> --
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>