After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 131131 - Power connection image doesn't update
Power connection image doesn't update
Status: RESOLVED FIXED
Product: gnome-applets
Classification: Other
Component: battery
2.5.x
Other Linux
: Normal major
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-01-11 01:27 UTC by Lasse Bang Mikkelsen
Modified: 2010-01-24 01:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Lasse Bang Mikkelsen 2004-01-11 01:27:10 UTC
Battery Charge Monitor doesn't update the image which indicate the
status of the power connection on a laptop (ACPI). If I boot with my AC
adaptor connected the image is correct, but if I disconnect it, it just
continue showing that image (AC adaptor connected). The same the other
way around.
                                                                          
     
Steps to reproduce the problem:
1. Connect AC adaptor
2. Start the applet
3. Disconnect the AC adaptor
                                                                          
     
How often does this happen?
Always.
Comment 1 Klaus Reichl 2004-02-26 14:50:34 UTC
I can reproduce the described bug on my Compaq Evo N600C / Linux 2.6.3
/ Debian sarge (Battery Charge Monitor 2.4.0) under certain load
conditions.

Reason is a race between `acpi' daemons socket write and the read
logic in battstat/acpi-linux.c:acpi_process_event.  The read() may get
a junk without '\n' with the rest comming in with the next junk.

Note that the bug has been fixed (by side effect?) in 2.5 using
g_io_channel_read_line_string.  NB: 2.5 Code I have from garnome
2.30.1 doesn't g_free a g_string_new'ed buffer. 

The fix:
--- acpi-linux.c~       2004-02-26 09:49:20.000000000 +0100
+++ acpi-linux.c        2004-02-26 15:41:07.000000000 +0100
@@ -336,9 +336,19 @@
     char str[256];
     gboolean result = FALSE;
 
-    i = read(acpiinfo->event_fd, str, sizeof(str)-1);
+    /* We assume line buffering here, so read until we really have 
+       a full line, if we don't do that we may get text without '\n'
+       and a preceding '\n' in the next chunk */
+    i = 0;
+    s = str;
+    do {
+      i += read(acpiinfo->event_fd, s, sizeof(str)-1-i);
+      s = &str[i];
+    } while (str[i-1] != '\n');
+
     str[i] = '\0';
     s = str;
+
     while ((evt = parse_acpi_event(s, &s)) != ACPI_EVENT_DONE) {
       switch (evt) {
         case ACPI_EVENT_AC:
Comment 2 Danielle Madeley 2004-05-23 17:15:14 UTC
I remember this error. It definitely appears to be resolved in GNOME 2.6, and
I'm fairly sure it's resolved in Debian (Unstable at least).

I'm going to CLOSE this, REOPEN if it's still persistant.
Comment 3 Lasse Bang Mikkelsen 2004-05-31 16:03:35 UTC
Upgraded to GNOME 2.6.1 and the problem still persists! I reopened the bug.
Comment 4 Danielle Madeley 2004-05-31 16:28:21 UTC
Ok, what version of ACPId are you using? What kernel version are you using?

For example, it seems fine with ACPId 1.0.3 and Linux 2.6.6.
Comment 5 Lasse Bang Mikkelsen 2004-05-31 16:34:52 UTC
Same here. Hmm, this seems like a ACPI bug then.
Comment 6 Danielle Madeley 2004-05-31 16:39:49 UTC
Is your system receiving ACPI events correctly from ACPId?

Check ACPId is creating the pipe /var/run/acpid.socket
Comment 7 Lasse Bang Mikkelsen 2004-05-31 16:46:27 UTC
srw-rw-rw-    1 root     root            0 May 31 16:36 /var/run/acpid.socket

It does.
Comment 8 Lasse Bang Mikkelsen 2004-05-31 16:48:43 UTC
/proc/acpi/ac_adapter/ACAD/state seems functional also.
Comment 9 Danielle Madeley 2004-06-01 03:51:56 UTC
ACAD, is this a typo?
I have a /proc/acpi/ac_adapter/ADP1/state not an ACAD/state
Comment 10 Lasse Bang Mikkelsen 2004-06-01 06:13:57 UTC
No it isn't.
Comment 11 Danielle Madeley 2004-06-01 06:22:50 UTC
As far as I can see, the GNOME applet never references a particular path for the
AC adapter. It either:
 1) parses /proc/acpi/ac_adapter/* for a status (done first time), or
 2) parses an event from the ACPI event system.
Since it gets it right first time. This would indicate a problem with part 2.
Examining part 2, it looks for an ac_adapter event from the events pipe.

I get the impression that this is a bug in ACPId, which is probably not
understanding the events queue properly. If you could get some output from
/proc/acpi/events and some output from /var/run/acpid.socket we could confirm this.

Tentatively, NOTGNOME.
Comment 12 Danielle Madeley 2004-06-01 06:40:17 UTC
Filed a bug with Debian (#252024)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252024
Comment 13 Cajus Pollmeier 2004-06-01 07:31:08 UTC
Debian acpid ships with a programm which listens on the acpid socket and  
outputs all data from there. It is called acpi_listen. Please check if  
this program is reporting the events.  
  
If it does not: your kernel is buggy.  
If it does: your gnome applet fails to read the socket in a correct way  
  
Hope it helps. I've closed the bug like I did last time I got exactly  
the same message. Can't reproduce these problems with acpi_listen, sorry.  
  
Cheers,  
Cajus  
Comment 14 Lasse Bang Mikkelsen 2004-06-01 16:05:14 UTC
Fired up acpi_listen and got this output when I connect/disconnect my AC adapter:

battery BAT1 00000080 00000001
Comment 15 Danielle Madeley 2004-06-01 16:44:11 UTC
Ok, checking it out here...

Disconnecting the ac power:
ac_adapter ADP1 00000080 00000000  <-- ac event
processor CPU0 00000080 00000000   <-- cpu scaling event (we can ignore this)

Reconnecting the power:
ac_adapter ADP1 00000080 00000001  <-- ac event
processor CPU0 00000080 00000000   <-- cpu scaling event (we can ignore this too)

Intermittantly, at a certain timeout interval:
battery BAT1 00000080 00000001     <-- a battery discharing event

It would seem for some reason that your machine is not sending the acpi event to
say the power has been disconnected/reconnected.
Comment 16 Lasse Bang Mikkelsen 2004-06-01 20:41:38 UTC
Hmm, but it seems the ACPI /proc code in the kernel is functional. What
interface is used by acpid to fetch events?
Comment 17 Danielle Madeley 2004-06-02 02:34:58 UTC
It comes from /proc/acpi/events
Comment 18 Lasse Bang Mikkelsen 2004-06-02 16:54:15 UTC
Hmm, after dist-upgrading my system the applet works! I updated three days ago
with no luck, it seems somebody upgraded something - acpi_listen doesn't report
any ac_adapter events though.

Marked this bug as FIXED.