Bug 162859 - [acpi] ACPI battery/acline monitoring partialy working (switching)
Summary: [acpi] ACPI battery/acline monitoring partialy working (switching)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.0-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Jung-uk Kim
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-24 21:50 UTC by msuszko
Modified: 2015-01-26 21:21 UTC (History)
5 users (show)

See Also:


Attachments
dmesg.vorbose+shutdown+normal (48.38 KB, text/plain; charset=UTF-8)
2012-08-16 17:21 UTC, kamikaze
no flags Details
An image showing the problem: state: discharging, correct value: charging (164.11 KB, image/jpeg)
2014-11-24 16:07 UTC, Anders Bolt-Evensen
no flags Details
A patch to test (1.95 KB, patch)
2015-01-20 00:42 UTC, Jung-uk Kim
no flags Details | Diff
A patch to test (2.73 KB, patch)
2015-01-20 05:38 UTC, Jung-uk Kim
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description msuszko 2011-11-24 21:50:08 UTC
This problem is similar to kern/160838, but in my case - acpiconf -i batt show all the information (AC adapter connected):

tlhscd@arsenic:~ $ sysctl hw.acpi.acline
hw.acpi.acline: 1

tlhscd@arsenic:~ $ acpiconf -i batt
Design capacity:        4241 mAh
Last full capacity:     4241 mAh
Technology:             secondary (rechargeable)
Design voltage:         14400 mV
Capacity (warn):        213 mAh
Capacity (low):         43 mAh
Low/warn granularity:   100 mAh
Warn/full granularity:  100 mAh
Model number:           Primary
Serial number:          11436 2010/03/05
Type:                   LIon
OEM info:               Hewlett-Packard
State:                  charging 
Remaining capacity:     99%
Remaining time:         unknown
Present rate:           341 mA (5703 mW)
Present voltage:        16727 mV

After disconnecting AC adapter, acpiconf shows the battery is discharging, but remaining capacity, time and rates does not change:

tlhscd@arsenic:~ $ sysctl hw.acpi.acline
hw.acpi.acline: 0

tlhscd@arsenic:~ $ acpiconf -i batt
Design capacity:        4240 mAh
Last full capacity:     4240 mAh
Technology:             secondary (rechargeable)
Design voltage:         14400 mV
Capacity (warn):        212 mAh
Capacity (low):         43 mAh
Low/warn granularity:   100 mAh
Warn/full granularity:  100 mAh
Model number:           Primary
Serial number:          11436 2010/03/05
Type:                   LIon
OEM info:               Hewlett-Packard
State:                  discharging 
Remaining capacity:     100%
Remaining time:         1:13
Present rate:           3450 mA (57756 mW)
Present voltage:        16741 mV

Reconnecting AC adapter back does not change computer state - acpiconf shows the same message, hw.acpi.acline is still 0.

How-To-Repeat: Boot machine with AC adapter connected, login to system, disconnect and reconnect AC adapter.

The above is observed on HP nx7300 laptop with those settings in rc.conf:
performance_cx_lowest="HIGH"
economy_cx_lowest="LOW"

Setting debug.acpi.max_tasks as temporary fix like in kern/160838 does not work for me.

As far as I remember - in 8.2-STABLE all worked as expected.
Comment 1 oliver.pntr 2011-11-24 22:14:04 UTC
Same situation here, my laptop is HP ProBook 5310m.
Comment 2 Mark Linimon freebsd_committer 2011-12-30 00:48:04 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-acpi

Over to maintainer(s).
Comment 3 spell 2012-03-07 09:51:03 UTC
Same situation here, my laptop is HP Compaq 530.
(Excluding there is no debug.acpi.max_tasks on my sysctl tree).
Things were working excellently until upgrading from 8.2 to 9.0.
Comment 4 spell 2012-03-16 08:43:12 UTC
I have discovered one thing about this: when you ask the value of
hw.acpi.battery first time after boot, you get real values (life,
time, state), but every next query gives the same numbers as first.

Maybe there is some locking/blocking?
Comment 5 iasen.kostov 2012-08-02 13:28:20 UTC
Same here - HP ProBook 4530s.
FreeBSD HeadBanG 9.1-BETA1 FreeBSD 9.1-BETA1 #2: Sun Jul 15 08:27:11
EEST 2012     root@HeadBanG:/usr/obj/usr/src/sys/HEADBANG  amd64
In ~99% of the battery events they are not registered (eg: charging,
pulling/plugging the power cord). The laptop has the latest BIOS from
HP and it came with SUSE where the battery indicator worked as it
should. Now it has windows (because it's useless under FreeBSD in the
current state) and of course it works under windows too. I'm way too
far from the inner workings of ACPI to be able to easy investigate
this :( .

Regards, Iasen.
Comment 6 kamikaze 2012-08-16 17:21:02 UTC
I have this issue with my HP 6510b Core 2 Duo 2.4 GHz ICH8 system.

Attached is a verbose boot dmesg and shutdown and a regular boot.

I'm willing to provide dmidecode and pciconf output or run experimental
kernel patches. Whatever is necessary to fix this.

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?
Comment 7 slynko 2013-04-30 09:51:35 UTC
I have the same issue with HP EliteBook 8540p
Comment 8 joseph 2013-11-09 12:25:26 UTC
Count one more. I updated from FreeBSD 8.2, where the acpi battery
status worked, to 9.2 where it does not.
The battery charging level and state won't be updatet, means if i start
with or without cable the charging level and state remain unchanged up
to the next reboot. I use an HP 625.
Comment 9 freebsd 2014-01-01 23:27:27 UTC
Same here, it used to work ok on 8.x, on 9.2 it's broken like described
above. HP Compaq 8510p.
Comment 10 Anders Bolt-Evensen 2014-11-24 16:07:16 UTC
Created attachment 149774 [details]
An image showing the problem: state: discharging, correct value: charging

Image showing the problem:
The orange light indicates that the power cable is connected and that the battery is charging (if the battery is fully charged, there would be a green light instead of an orange one). The "acpiconf -i0" command that is shown on this photo is run AFTER the cable has been connected. If you take a look at the line saying "State:" you see the incorrect value "discharging". There the correct value would be "charging" instead, because the battery is charging instead of discharging.
Comment 11 Anders Bolt-Evensen 2014-11-24 16:12:00 UTC
I also have pretty much the same problem.
The only difference is that I'm on a MacBook Pro from 2011, running in UEFI mode on FreeBSD 11. The problem also exists in CSM (BIOS) mode on FreeBSD 10 and 9, Also see the attached photo and its comment.
Comment 12 juris 2014-12-10 11:16:03 UTC
Battery status only updates after reboot on HP 8440p and for all HP laptops as it seems from previous comments as of Freebsd 9.0 - Release

Current workaround:
Install Freebsd 8.4 - Release and do not upgrade
Comment 13 Anders Bolt-Evensen 2014-12-20 16:29:11 UTC
It also seems to work on my MacBook Pro when I run FreeBSD 8.4 (but because of lack of features like KMS, running 8.4 is not really an option to me).
If someone could put the code related to this issue from 8.4 to 10.X and CURRENT it would be great. :)
Comment 14 juris 2015-01-03 11:45:05 UTC
Problem on /head/ branch is introduced with revision 216942.
Comment 15 smithi 2015-01-13 08:23:19 UTC
(In reply to juris from comment #14)
From correspondence in freebsd-acpi@:

 > > > So, reverting rev 216942 fixes it for you?  On what FreeBSD version?
[..]
 > Sorry for my previous email that was confusing. I did not revert r216941
 > when compiled release 9.3. So when I did that, battery status works. I also
 > compiled release 10.1 with excluding r216942, and battery status works. So
 > this single change for some reason creates problem for HP laptops.

Note that this PR was originally filed on 2011-11-24 at version 9.0-PRERELEASE.  Revision 216942 was committed to head on Jan 4 2011 (4 years ago) by jkim, 6
days before 9.0-RELEASE, While head was 9-CURRENT, and has not changed since.

Fortunately for these HP laptops and a Macbook Pro anyway, this change was not
apparently merged back to 8.x so this problem does not occur for these on 8.x

It remains to be seen if just reverting r216942 adversely affects any others.

Ian
Comment 16 Jung-uk Kim freebsd_committer 2015-01-20 00:42:14 UTC
Created attachment 151870 [details]
A patch to test
Comment 17 Jung-uk Kim freebsd_committer 2015-01-20 00:42:59 UTC
Please test the patch.
Comment 18 Jung-uk Kim freebsd_committer 2015-01-20 05:38:11 UTC
Created attachment 151884 [details]
A patch to test
Comment 19 Michael Lackner 2015-01-23 14:56:42 UTC
(In reply to Jung-uk Kim from comment #18)
I just tried your patch, and it seems it makes things even worse. I am on a HP/Compaq nx6310 (i386 arch) with similar problems.

With the vanilla 10.1-RELEASE kernel, only the very first state transition is recognized (e.g. pulling the AC cable). Any further events are completely ignored, whether is connecting/pulling the AC plug or letting the battery drain.

After applying your patch, no state transition is recognized anymore, not even the initial one. ACPI only shows the state of the battery at initialization/boot time.

acpiconf -i0 shows the single installed battery both with and without patch as "secondary".

I also tried to fix the errors shown by iasl in HPs DSDT when attempting to recompile the ACPI bytecode. However, when loading the "fixed" code via /boot/loader.conf, it will not overwrite the BIOS' DSDT for reasons unknown.

More information here:
https://forums.freebsd.org/threads/battery-status-on-hp-compaq-nx6310.49542/

I'd be okay with a kernel patch instead of ACPI table patch, but this one here only broke it even more for me.
Comment 20 juris 2015-01-23 15:17:43 UTC
You can try to compile 10.1-release but without code introduced with r216942 (on head branch).
This has worked for HP Elitebook, MacBook Pro. If it fixes for you, then this issue described here relates also to HP Compaq.
(In reply to Michael Lackner from comment #19)
Comment 21 Michael Lackner 2015-01-23 15:20:42 UTC
(In reply to juris from comment #20)
Isn't this exactly what Jung-uk Kims patch is doing? Getting rid of the changes in r216942? I might need to recheck and compare the patch with r216942, but at first glance it looked like it was just to revert back from r216942.
Comment 22 commit-hook freebsd_committer 2015-01-23 18:12:50 UTC
A commit references this bug:

Author: jkim
Date: Fri Jan 23 18:12:44 UTC 2015
New revision: 277579
URL: https://svnweb.freebsd.org/changeset/base/277579

Log:
  Revert r216942.  This commit was premature and caused too many complaints.

  PR:		162859
  MFC after:	3 days

Changes:
  head/sys/dev/acpica/acpi_ec.c
Comment 23 Jung-uk Kim freebsd_committer 2015-01-23 18:16:04 UTC
(In reply to Michael Lackner from comment #21)
No, it was my last attempt to keep the commit.  I just fully reverted r216942 and it will be MFC'ed in three days.
Comment 24 Michael Lackner 2015-01-23 22:02:49 UTC
(In reply to Jung-uk Kim from comment #23)

I see! I was not comparing your patch and r216942 thoroughly enough, my apologies for that.

After having a few beers, I just downloaded the reverted acpi_ec.c and recompiled 10.1-RELEASE with it.

First impression: Awesome!

I tested AC transitions multiple times, and also tested battery draining/recharging and full charge states while running the kernel in verbose mode. It all seems to work just fine on my HP/Compaq nx6310 now, finally making it fully fit for productive use.

I assume this fixes the issue on all HP/Compaq nc6xxx and nx6xxx notebooks as they seem to share the same ACPI DSDT code, judging from the header of said ACPI code when dumped from my books BIOS.

Well, thank you very much for your work, and cheers!
Comment 25 Jung-uk Kim freebsd_committer 2015-01-26 21:21:42 UTC
Merged to stable/10 and stable/9.