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.
Same situation here, my laptop is HP ProBook 5310m.
Responsible Changed From-To: freebsd-bugs->freebsd-acpi Over to maintainer(s).
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.
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?
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.
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?
I have the same issue with HP EliteBook 8540p
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.
Same here, it used to work ok on 8.x, on 9.2 it's broken like described above. HP Compaq 8510p.
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.
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.
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
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. :)
Problem on /head/ branch is introduced with revision 216942.
(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
Created attachment 151870 [details] A patch to test
Please test the patch.
Created attachment 151884 [details] A patch to test
(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.
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)
(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.
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
(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.
(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!
Merged to stable/10 and stable/9.