You are not logged in.
I am running arch on a macbook pro 9,2. When my laptop is plugged in during the bootup process, arch detects my battery (and continues to detect it even if I remove AC power after bootup). When my laptop is not plugged in during the bootup process, arch does not detect my battery (and continues to not detect it even if I connect AC power after bootup). This does not affect performance - arch still works just fine and runs on battery power, but I cannot see how much juice the battery has left if the system is not connected to AC power during bootup. OS X (I am dual booting) detects the laptop battery just fine irrespective of whether or not the laptop is plugged in during bootup.
By "plugged in/connected to AC during bootup" I mean that the laptop was plugged in before I powered it on and remained plugged in during bootup (as opposed to the alternative grammatical interpretation that the laptop was not plugged in and then I powered it on and plugged it in before the bootup process completed).
By "arch does not detect my battery" I mean that the "Battery Monitor" applet on my xfce panel does not function (claims 50% charge at all times and does not show whether AC is connected or not), and that
# acpi -b
and
# dmesg | grep battery
both give empty outputs. Thoughts?
Offline
Run lsmod in both states and see what, if any, difference there is...
Also, try running udevadm monitor whilst pluggin/unplugging the cord. See the wiki article on udev for details.
Offline
Checked lsmod when battery is detected and when it is not - there is no difference. When my system detects the battery, I run udevadm monitor, and I unplug the power cord I get
KERNEL[1778.845026] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [1778.846289] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
When my system detects the battery and I plug the cord back in, udevadm monitor gives
KERNEL[1787.272423] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [1787.273831] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
When my system does not detect the battery, unplugging the power cord yields
KERNEL[164.507689] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [164.508913] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
And plugging it back in yields
KERNEL[168.225331] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [168.226736] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
Offline
So, when the battery is not being picked up correctly (and you are not running on AC), can you read a charge in /sys/class/power_supply/BATx?
Offline
I am having the same issue on MBP 8.2. I am too lazy/busy to investigate...
Offline
Looks like a kernel problem. Perhaps downgrading/changing kernel?
----- Think out of the Box. ------
Archer since 2010.
My projects: http://github.com/kinokoio
Offline
Jason: No. When the battery is not being picked up correctly (and AC is not connected) the only folder in /sys/class/power_supply/ is ADP1, whereas when the battery is being picked up correctly (AC still not connected) I can find both the ADP1 and BAT0 folders in /sys/class/power_supply/ and can find in BAT0 the current charge, etc.
Kinokoio: I am using linux-grsec instead of the standard linux kernel. I checked your hypothesis by changing back to vanilla linux, and you would seem to be correct. I rebooted three times under the vanilla linux kernel (with no power cord attached), and each time my battery was correctly detected. I then changed back to linux-grsec and rebooted (still no power cord attached) and my battery was once more not properly detected. Returning to vanilla linux would thus seem to be a possible "solution," but I am not yet ready to give up on trying to figure out where the actual problem lies.
Offline
I am using linux-grsec instead of the standard linux kernel.
That information should have been in your first post.
Read the kernel docs and look at some of the acpi options you can add to the kernel line. I have no idea about -grsec, though...
Offline
I assume you downgraded to the linux-3.17.x package in [core]. linux-grsec is 3.18.1. linux in [testing] is 3.18.2. I am affected with linux in [testing].
This has nothing to do with grsec. It is all due to something in the 3.18 update. You will see the issue again in a few days when 3.18 hits [core].
Offline
Apologies for leaving off which kernel I was using (I did not know at first that it was a kernel issue).
Allan: Yes, you are quite right. linux-grsec is 3.18.1 and when I reverted to vanilla linux I changed to linux-3.17.6 in [core]. I suppose it is comforting that the problem will soon hit enough macbook arch users that others may figure it out, should I fail to do so.
In any case, in the interim I will continue to search for the problem and if I come up with a solution I will post it here.
Offline
Hi, same problem here…battery not detected, just today I have upgraded to kernel 3.18, so I'll downgrade most probably…
Offline
I've got the same problem since 3.18 with a MacBook Pro 9,2. It's intermittent whether the battery is detected on boot, though, and it's sometimes detected when I boot without the AC charger in.
Offline
Also experiencing this issue. Have tried multiple boot options for
acpi_osi=___
including Linux and Darwin.
Sometimes I can get "acpi" output, and even when I do, eventually it will revert back to null output.
Relevant info:
Macbook Pro 8,2
3.18.6-1-ARCH
"acpi -V" output when not responding:
Adapter 0: on-line
Cooling 0: x86_pkg_temp no state information available
Cooling 1: intel_powerclamp no state information available
Cooling 2: Processor 0 of 17
Cooling 3: Processor 0 of 17
Cooling 4: Processor 0 of 17
Cooling 5: Processor 0 of 17
Cooling 6: Processor 0 of 17
Cooling 7: Processor 0 of 17
Cooling 8: Processor 0 of 17
Cooling 9: Processor 0 of 17
Willing to give any additional info needed.
Offline
I've only given it a day, and I'm not sure WHY this fixed it, but I think I found a combination of boot options that give me acpi output:
options root=PARTUUID=my_uuid rw irqpoll acpi_osi=Darwin
I think the thing that helps it is "irqpoll", as it would sometimes give me an error about irq 17 on boot. Hopefully this helps someone. I'll update again if this turns out to be worthless.
Offline
Nevermind, still is variable whether or not it'll actually give me ACPI output with any of these options. Anyone have suggestions on where to start looking or how to go about troubleshooting this?
Offline
I am also experiencing this issue - can provide details if needed:
MacBook Pro 8,1
Kernel: 3.18.6-1-ARCH
Offline
I've managed to get battery life detection on battery boot, though I'm not sure if it's a fluke. Here's some info that might help:
Booting with options "rw acpi_osi=Linux"
Installed powertop-git and powerdown-git
Added these files:
# /etc/modprobe.d/i915.conf
options i915 enable_rc6=1 enable_fbc=1 lvds_downclock=1
# /etc/modprobe.d/usbcore.conf
options usbcore autosuspend=1
# /etc/modprobe.d/snd_hda_intel.conf
options snd_hda_intel power_save=1
I don't think any are particularly relevant aside from powerup/powerdown, but that's what I've done since my last reboot and it seems to be working now...fingers crossed.
Offline
Hi parades:
Your solution did not work for me, though I appreciate you sharing what worked for you.
I downgraded to the LTS kernel and the battery was recognized.
Unfortunately, my wifi quite with the LTS kernel - so I returned to kernel 3.18-6.
I was wondering how to determine if there is a bug report for this in the linux kernel? Where does one go to look for or make such a bug report?
Offline
Yeah it actually doesn't work 100% of the time, but it's more reliable than it was before.
Thinking of doing a re-install next week, and might just compile the new mainline with it. We'll see...
Offline
Just as an update, upgrading the kernel to 3.19.2-1-ARCH didn't work
Offline
I got a Macbook Pro 13'', 9,2 (Mid 2012) and I experience the exact same issues with kernel 3.19.3-3-ARCH.
Don't know what to do
Offline
I combined the LM Sensors and the ACPI and the Linux on Macbook where it sais about the 2 modules.
Therfore I have these:
# cat /etc/modules-load.d/load_these.conf
coretemp
applesmc
# cat /etc/conf.d/lm_sensors
# Generated by sensors-detect on Fri Apr 10 16:52:37 2015
# This file is sourced by /etc/init.d/lm_sensors and defines the modules to
# be loaded/unloaded.
#
# The format of this file is a shell script that simply defines variables:
# HWMON_MODULES for hardware monitoring driver modules, and optionally
# BUS_MODULES for any required bus driver module (for example for I2C or SPI).
HWMON_MODULES="coretemp applesmc"
I have rebooted 3 times plugged and/or unplugged and changing while laptop is functioning and I have no issues.
I am not sure that what I did was right and whether if it's gonna be permanent
Offline
@redsolja your solution worked for me too, however I had to edit /etc/modules as per the site https://medium.com/@PhilPlckthun/arch-l … a525ebefe3
We need to enable some kernel modules, that we will need later for fan speed and the temperature sensors:
nano /etc/modules
Insert these two lines:
coretemp
applesmc
Save and exit.
Offline
It does not work 100% of the time, even with these modules (although I don't know if there is any difference adding modules at /etc/modules or at /etc/modules.d/load-these.conf - I have the same at both).
As for the problem itself, it seems that when my battery is full and I am not charging it, the battery still does not get detected.
I am open for any other suggestions.
Offline
I've had those two set for a while for mbpfan. I have the most luck now with acpi_osi="Darwin" (not sure if quotes matter or if it's placebo but it's been at its best with that exact format). I'm fine with looking into fixing this in a real way, problem is I don't know where to start looking. Clearly different acpi_osi entries change how the battery gets detected. Guessing this is parsed in kernel in it somewhere?
Offline