Red Hat Bugzilla – Bug 100540
battery monitoring applet crashes on severn
Last modified: 2014-03-16 22:37:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
(beta component doesn't show up in bugzilla... the step by step bug entry form
sucks bigtime, btw)
When trying to add the battery monitoring applet to the gnome panel in a full
severn install, the applet (/usr/libexec/battstat-applet-2) crashes (as does bug
buddy when using that to get details :D ) immediately.
It's worth noting that the laptop (a centrino laptop) doesn't have APM support -
it uses ACPI for everything of that nature (and thus, the battery info is found
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add battery monitoring applet to gnome panel.
Actual Results: It crashed.
Expected Results: It shouldn't crash.
It appears you *must* have all the correct ACPI modules loaded, otherwise it
# modprobe ac
# modprobe battery
the applet runs and does not crash.
It appears that somehow the install needs to figure out ACPI needs to be on and
adds the appropriate modules when the system boots.
I added them to the /etc/init.d/acpid
--- acpid.orig 2003-07-24 12:28:11.000000000 -0400
+++ acpid 2003-07-24 12:27:49.000000000 -0400
@@ -27,6 +27,10 @@
if [ ! -f /var/lock/subsys/$PROGNAME ]; then
echo -n $"Starting acpi daemon: "
modprobe button > /dev/null 2>&1
+ modprobe battery > /dev/null 2>&1
+ modprobe ac > /dev/null 2>&1
+ modprobe processor > /dev/null 2&1
+ modprobe thermal > /dev/null 2&1
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$PROGNAME
Using those modules does solve the problem...
One thing I have noticed though is that battstat-applet-2 consumes 10-15% of the
processor though. It appears that it is the polling of the /proc interface that
causes it, although I have not had time to test that yet.
Ok, the cpu problem is just accessing the /proc/acpi information.
Should I change the topic on this, or create a new incident?
On my Dell Latitude C400, accessing the ACPI information spikes the proccessor
up to 10%-15%.
I tested this by running:
$ watch "cat /proc/acpi/ac_adapter/AC/state ; cat /proc/acpi/battery/BAT0/state"
I then watched the cpu usage every second, and it would fluctuate from around
1%-2% when /proc/acpi entries were not being accessed to 10%-15% when they were.
I watched by using top and gnome-system-monitor.
Yes, the cpu issue should be a different bug; that's a kernel issue.
Yep, over the weekend I reached a similar config. One needs to load the
*** Bug 102735 has been marked as a duplicate of this bug. ***
This is perhaps 3 or 4 separate bugs.
1) Crashing of applet which shouldn't happen. It should warn that the kernel
modules are not loaded so it cannot query battery info.
2) Kernel modules should be loaded automatically?
3) Too much overhead/too expensive when reading battery state from /proc. I've
seen older versions of 2.4.x with ACPI lockup completely or lose PS/2 devices
after polling the battery state in /proc several times. The kernel just isn't
handling this situation well.
4) The gnome applet is polling too quickly. It is nowhere near this bad with
the KDE battery applet.
Should we file the sub-bugs?
Closing the original bug as it is fixed... when the kernel changed to acpi to
default to off (I thought it was just a broken kernel for a while), the applet
didn't crash. File the rest separately.