Solved Battery status on HP/Compaq nx6310

Hello,

I am currently using FreeBSD 10.1-RELEASE on a HP/Compaq nx6310 laptop with a 32-Bit x86 CPU, and it's working pretty well so far.

I do have one hardware-related problem left though, and that's with checking the battery status of the system.

It would be pretty helpful to actually know the current charge level of the battery when sitting in a longer meeting for instance.

What happens is this: The system will know the status of the battery and AC plug on boot. It will also recognize a single state transition. For instance: If I have the AC plug connected and I disconnect it, this change will be reflected in ACPI as I can verify using the Xfce4 battery monitor or hwstat after a few seconds after the change.

Any subsequent changes are ignored however. After an initial AC disconnect, the battery status will be "discharging", and sit at 99% or 98% charge until the system runs out of battery charge or is being rebooted. If AC is reconnected, the event is no longer recognized and the state will remain "discharging".

I suspect this to be some ACPI bug, but I am unsure as to how to proceed. I have dumped and disassembled my ACPI tables using acpidump and iasl by running # acpidump -d > acpidump-nx6310-disassembled.txt, you can find that file attached to this post. I decided to attach the whole 544kb file just in case.

My problem is, I have zero ACPI knowledge, but maybe somebody here can help? It just feels terrible not to know the charge level, there is always this latent fear that it can go "snap" anytime and it's gone with still mounted file systems being dirty and damaged and stuff like that.

I also searched the web for this and found several people having problems like this one for several major releases of FreeBSD. I could not find any solutions though.

Thanks!
 

Attachments

  • acpidump-nx6310-disassembled.txt
    544.3 KB · Views: 360
Unfortunately ACPI battery support is very broken for many HP notebooks. :(
 
Yeah, that's the impression I got when reading reports and threads about it on the web. I just thought some ACPI hacker might know a way to fix this somehow. Maybe I should study ACPI, but it looks nasty enough for me to be a bit reluctant to dive into this matter. Looks like it's a bit over my head. The relevant code block for the primary battery (I do not have a secondary one) seems to be this:

Code:
Device (C1BC)
  {
    Name (_HID, EisaId ("PNP0C0A")) // _HID: Hardware ID
    Name (_UID, 0x01) // _UID: Unique ID
    Method (_STA, 0, NotSerialized) // _STA: Status
    {
      Return (\_SB.C002.C003.C005.C1AA (0x01))
    }

    Method (_BIF, 0, NotSerialized) // _BIF: Battery Information
    {
      Return (C1AC (0x00))
    }

    Method (_BST, 0, NotSerialized) // _BST: Battery Status
    {
      Return (C1B0 (0x00))
    }

    Name (_PCL, Package (0x01) // _PCL: Power Consumer List
    {
      \_SB
    })
  }
I just don't know what to make of this.
 
Yes, it's just that I am not sure whether I'm doing it right. I subscribed to that mailing list, but I didn't get any confirmation email and also no regular mails from any subscribers. I'll try again later. I also had trouble registering with FreeBSDs Bugzilla once, and on my second attempt it worked just fine.
 
GrandAdmiralThrawn You don't need to be subscribed to the list. Just send the mail to its email address and be sure to ask people to in CC you in their replies.
 
My apologies for the double post, but I wrote to the list on 31st of December, and I have not received any replies so far. It's only been a week, plus new year and all, but I'm still not sure whether the list ever properly received my post. I didn't get any confirmation or error message back from the mail/list server, so I'm unsure whether there just is nobody who can help with my problem or whether nobody ever got to even read my email. That's why I'd like to ask again here. Maybe somebody here reads freebsd-acpi@freebsd.org and can confirm my problem was posted ok?

Its like working with a black box. ;) I can put stuff in, but other than that, I have no idea what's going on. ;)

Reason for my uncertainty is also that I failed to ever receive anything from the server when trying to subscribe to the list beforehand.

Thanks!
 
I don’t find your message in the list archives. I’m not sure that you are allowed to send messages to the list without being subscribed, but lme@ knows better than me. Nevertheless, you could try subscribing, the list seems quite alive.
 
Ah, thanks for the link, my bad. I should've checked more thoroughly.

My post is indeed not there. And no error message from the mail server either, so no idea what went wrong. I tried to subscribe here. I just tried a for a third time, and the website always shows this after submitting the web form:
https://lists.freebsd.org/mailman/subscribe/freebsd-acpi said:
freebsd-acpi Subscription results

Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator. If confirmation is required, you will soon get a confirmation email which contains further instructions.


And that's it. Maybe the list moderator has to approve my request, and that person is currently unavailable or has no time at the moment. The web form is extremely simple, and I double-checked my email address before submitting, there shouldn't be any mistake there. I'm not using a "spammers domain name" either, in case there is a blacklist. I have my own domain, so that shouldn't be the cause.

My email server has no greylisting, so any email sent from the FreeBSD server should get through without issues, also works fine for web shops, forums, eBay etc.

Any ideas as to what else I might try to get on the list? Or what I might do wrong?
 
Oh, sorry. I didn't know acpi@ was moderated. Some lists are, some are not...
 
It seems I can't get onto the mailing list, so in my complete desperation I tried to begin to fix the DSDT myself. It seems HP compiled it using the Microsoft ASL compiler, and now I tried to recompile it using Intels iasl. It seems iasl is far more strict in its checking, so there were 2 errors, 17 warnings and countless remarks at my first attempt.

Using Google I managed to find out what all of that was, and fix it (or so I hope). In the end, I managed to get to a build with 0 errors, 0 warnings, 0 remarks. Also, I spotted OS specifics for Windows XP, XP SP1, XP SP2 and what I believe to be Windows Vista. I tried to fake the OS name as shown in the ASL source code by entering the following into /boot/loader.conf:

Code:
hw.acpi.osname="Windows 2006"

Now, I'd like to load my recompiled aml binary in /boot/loader.conf, as per the FreeBSD handbook:

Code:
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/nx6310.aml"

After a reboot, nothing changed. So i dumped and decompiled the tables again, and got the old ones from the HP BIOS instead of my patched code. It seems my custom aml is not being loaded. Also, I can't see any errors regarding that part in /var/log/messages. When using the hw.acpi.osname setting, the log will show the osname override, so I'm thinking it should also tell when overriding the DSDT with a custom binary. But nothing.

I tried setting the permissions on /boot/nx6310.aml to 444 as well as 555. Also, I double-checked every line in /boot/loader.conf like 10 times, character per character.

Am I doing something wrong? Is the way to load a custom DSDT different in newer FreeBSD versions?

Thanks!

Edit: According to acpi(4) I am doing this correctly?!

Edit 2: I turned on verbose booting, and now get this line in /var/log/messages:

Code:
Preloaded acpi_dsdt "/boot/nx6310.aml" at 0xc18dcc34.

So it does load. Still, when running something like...

# acpidump -d > decompiled_dsdt.asl

... I still get the old, buggy code from the HP BIOS instead of from my preloaded /boot/nx6310.aml. Makes me tear my hair by now.

Edit 3: I tried the patch provided by Jung-uk Kim for PR 162859, but after applying it and recompiling + testing the new kernel, battery monitoring stopped altogether. Wouldn't even read static battery info via ACPI any longer, also didn't detect the first initial state transition anymore.

Edit 4:Fixed in r277579. Fix provided by Jung-uk Kim by reverting r216942, details in PR 162859.

Just downloaded the reverted /usr/src/sys/dev/acpica/acpi_ec.c, recompiled the 10.1-RELEASE kernel with it, tested AC state transitions, battery drain and battery charge multiple times, and it all works fine now!

Thanks fly out to Jung-uk Kim for the fix! Should be merged from current in 3 days.
 
Last edited:
Back
Top