I have a laptop running Linux 2.6.32-22-generic #33-Ubuntu SMP x86_64. My laptop is an ACER Aspire 6930. When I boot, the battery isn't enumerated into "sysfs" like gnome-power-manager expects it to be. After boot, the following command finds nothing: % find /sys -name "BAT1" -print If I inspect the contents of one of the files in the /proc/acpi/battery/BAT1 directory, they'll appear: % cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charged present rate: 0 mA remaining capacity: 3619 mAh present voltage: 12131 mV % find /sys -name "BAT1" -print /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1 /sys/class/power_supply/BAT1 This is repeatable on every boot. Once I "cat /proc/acpi/battery/BAT1/state", gnome-power-manager recognizes my battery (via upowerd) and all is well. This is the non-"gnome-power-manager" part of https://bugzilla.gnome.org/show_bug.cgi?id=617529 [I'll attach acpidump and dmesg output soon. Must reboot first.]
Created attachment 26482 [details] sudo acpidump > acpidump.log Output of acpidump after boot, before using previously described hack to "discover" my battery. After the hack to discover my battery, the output of acpidump didn't change.
Created attachment 26483 [details] cp /var/log/dmesg dmesg.log Copy of /var/log/dmesg immediately after booting. After using the previously described hack to discover my battery, there was no change.
There is an error in your BIOS, which prevents ACPI to properly find your battery, namely modification of namespace (add name _T_0) in unsynchronized method. _Q09 tries to add battery, but fails due to improper _T_0 interaction. Please check, if there is new BIOS for your machine.
Thanks. There is a new BIOS for my machine....but before I install it, we should probably finish addressing this problem more generally. Once I install the new BIOS, my problem might be gone, but other people's issues will remain. One bug per person affected isn't very efficient. Under Windows, my battery appears to be detected just fine. Under Linux, it isn't. Both Windows and Linux are booting on the same BIOS. I have a hack ("cat /proc/acpi/battery/*/state >& /dev/null") which works for discovering my battery properly after boot. Could a similar sort of fallback-mechanism be put into the boot sequence to mitigate the undesirable behavior in the event that the BIOS has this bug? Here is some evidence that this issue is broader than my case: https://bugzilla.gnome.org/show_bug.cgi?id=617529 http://www.mail-archive.com/universe-bugs@lists.ubuntu.com/msg187316.html And potentially: http://www.mail-archive.com/desktop-bugs@lists.ubuntu.com/msg339104.html https://bugzilla.gnome.org/show_bug.cgi?id=585890 http://linux.derkeiler.com/Mailing-Lists/SuSE/2010-02/msg01472.html Opinions?
Created attachment 26702 [details] custom DSDT please try the custom dsdt attached and see if the problem still exists.
ping...
close this bug as there is no response from the bug reporter.