oliver.pntr at gmail.com
Fri Nov 7 21:43:29 UTC 2014
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:
>> > > display broken". Looks like it's still the same problem, you were
>> > > 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:
> 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
>> > > logged? This smells a bit like some of the Embedded Controller
>> > > 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
>> > boot, shutdown and normal boot prepared, for whoever wants to look at
>> 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
>> > > 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.
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
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable