GNOME Bugzilla – Bug 617529
gnome power manager doesn't recognize battery at startup
Last modified: 2010-11-07 01:56:45 UTC
I've upgraded to Ubuntu 10.04. After startup on battery power, power manager icon that I am on AC power. (Plugging or unplugging AC adapter doesn't change anything.) I ran 'Raw ACPI Information' command as described on gnome power manager page: //for i in /proc/acpi/battery/*/*; do echo $i; cat $i; done The battery icon got restored, still no preferences options for battery power Runninng GNOME Power Manager Verbose Trace killall gnome-power-manager gnome-power-manager --no-daemon --verbose restored 'battery power' tab in preferences and returned message: (gnome-power-manager:1812): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.0/gobject/gsignal.c:2273: signal `proxy-status' is invalid for instance `0x9017970' after that the power manager icon disappeared from the panel on the desktop First time I ran verbose trace, I received a message that battery is in critical condition and needs to be replaced, showing its capacity at 23% However, the battery is almost new and had no problems until I upgraded to Ubuntu 10.04, last evening. Please let me know what to do and I will be happy to send any additional info. I pasted messages from my terminal below. Thanks, M. root@m-laptop:/home/m# for i in /proc/acpi/battery/*/*; do echo $i; cat $i; done /proc/acpi/battery/BAT1/alarm alarm: unsupported /proc/acpi/battery/BAT1/info present: yes design capacity: 5800 mAh last full capacity: 5676 mAh battery technology: rechargeable design voltage: 10800 mV design capacity warning: 560 mAh design capacity low: 168 mAh capacity granularity 1: 264 mAh capacity granularity 2: 3780 mAh model number: PA3734U-1BRS41167 serial number: 41167 battery type: Li-Ion OEM info: TOSHIBA /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 0 mA remaining capacity: 3215 mAh present voltage: 11038 mV root@m-laptop:/home/m# for i in /proc/acpi/battery/*/*; do echo $i; cat $i; done /proc/acpi/battery/BAT1/alarm alarm: unsupported /proc/acpi/battery/BAT1/info present: yes design capacity: 5800 mAh last full capacity: 5676 mAh battery technology: rechargeable design voltage: 10800 mV design capacity warning: 560 mAh design capacity low: 168 mAh capacity granularity 1: 264 mAh capacity granularity 2: 3780 mAh model number: PA3734U-1BRS41167 serial number: 41167 battery type: Li-Ion OEM info: TOSHIBA /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 0 mA remaining capacity: 3212 mAh present voltage: 11044 mV root@m-laptop:/home/m# killall gnome-power-manager root@m-laptop:/home/m# gnome-power-manager --no-daemon --verbose (gnome-power-manager:1812): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.0/gobject/gsignal.c:2273: signal `proxy-status' is invalid for instance `0x9017970' ^C root@m-laptop:/home/m# gconftool-2 -R /apps/gnome-power-manager /apps/gnome-power-manager/notify: fully_charged = false low_capacity = true perhaps_recall = true sleep_failed_uri = sleep_failed = true low_power = true discharging = true /apps/gnome-power-manager/statistics: data_max_time = 21600 smooth_data = true show_axis_labels = true show_events = true graph_type = power /apps/gnome-power-manager/backlight: brightness_dim_battery = 50 idle_dim_battery = true dpms_method_ac = off idle_dim_ac = false enable = true idle_brightness = 30 brightness_ac = 100 battery_reduce = true idle_dim_time = 10 dpms_method_battery = off /apps/gnome-power-manager/general: use_time_for_policy = true use_profile_time = true installed_schema = 3 network_sleep = false check_type_cpu = false /apps/gnome-power-manager/disks: spindown_enable_battery = true spindown_timeout_battery = 60 spindown_enable_ac = false spindown_timeout_ac = 600 /apps/gnome-power-manager/timeout: sleep_display_ups = 600 sleep_computer_ups = 0 sleep_display_battery = 600 sleep_display_ac = 1800 sleep_computer_ac = 0 sleep_computer_battery = 0 /apps/gnome-power-manager/info: history_type = charge stats_type = charge-data page_number = 0 last_device = /org/freedesktop/UPower/devices/battery_BAT1 /apps/gnome-power-manager/lock: gnome_keyring_suspend = false use_screensaver_settings = false blank_screen = false gnome_keyring_hibernate = true suspend = true hibernate = true /apps/gnome-power-manager/ui: show_actions = true enable_sound = true icon_policy = charge /apps/gnome-power-manager/thresholds: percentage_action = 2 percentage_critical = 3 time_action = 120 percentage_low = 10 time_critical = 300 time_low = 1200 /apps/gnome-power-manager/actions: sleep_type_battery = hibernate critical_battery = hibernate critical_ups = shutdown event_when_closed_battery = true sleep_type_ac = suspend low_ups = hibernate /apps/gnome-power-manager/buttons: power = interactive lid_ac = suspend suspend = suspend hibernate = hibernate lid_battery = suspend
I tried to follow all steps from the GNOME bug reporting guidelines but root terminal freezes after the first two lines in GNOME Power Manager Verbose Trace, gnome power manager crashes and gives message: battery is old or broken. After that battery charges erratically to 40-50% and shows that charge is full. After opening power manager from system menu battery power status restores to its 'normal' status, and battery can be charged up to 100% again.
Created attachment 160808 [details] [review] Patch to fix gnome-power-manager's part of Bug 617529.
This problem bit me too on Ubuntu 10.04, so I started digging... This is actually two separate problems: 1) The system is booting without all power devices being enumerated. 2) The gnome-power-manager isn't updating its capabilities once the battery is discovered. Issue #1: This isn't gnome-power-manager's fault. The upowerd daemon enumerates its devices through g_udev_client_query_by_subsystem() in "upower-0.9.1/src/linux/up-backend.c". The structure seen by these calls appears to match the /sys/class/ directory structure, and this structure hasn't been fully populated yet. By running: % cat /proc/acpi/battery/*/state the system will populate the /sys/class/power_supply directory with your batteries, and gnome-power-manager will then detect them. I'm don't know where the piece of code is that should enumerate all of the devices in the system and populate the /sys/class/ directory structure, but a separate bug should be filed on this. Issue #2: This is gnome-power-manager's fault. Killing and restarting gnome-power-manager after battery discovery works as a temporary hack, but attached is a patch for the code fix.
(In reply to comment #3) > By running: % cat /proc/acpi/battery/*/state > the system will populate the /sys/class/power_supply directory with your > batteries, and gnome-power-manager will then detect them. Ick. This is a kernel bug and needs to be fixed. Well done for find it tho. > I'm don't know where the piece of code is that should enumerate all of the > devices in the system and populate the /sys/class/ directory structure, but a > separate bug should be filed on this. Sure, the kernel should do it on cold-plug. > Issue #2: This is gnome-power-manager's fault. Killing and restarting > gnome-power-manager after battery discovery works as a temporary hack, but > attached is a patch for the code fix. Sure, the caps code was always pretty hacky, and is probably some of the oldest code in GPM. I've spent a bit of time this morning removing the caps code, and untangled g-p-prefs from the session g-p-m process. commit d23f4afbb99ad914ca0e33feff365d15a1e60532 Author: Richard Hughes <richard@hughsie.com> Date: Tue May 11 12:08:37 2010 +0100 Remove GetPreferencesOptions() and untie the preferences fro the daemon. Fixes #617529 This should fix the problem with the caps not being updated. If you could test git master I would very much appreciate it. Thanks.
Created attachment 161402 [details] [review] Patch for fixing SEGFAULT in first attempt to fix git master. The first attempt at fixing this bug in git master introduced a SEGFAULT by unreferencing an object still in use by a callback, thus allowing it to be freed while it was still in use. Attached is a patch that fixes that issue.
(In reply to comment #5) > The first attempt at fixing this bug in git master introduced a SEGFAULT by > unreferencing an object still in use by a callback, thus allowing it to be > freed while it was still in use. Where is GpmBrightness being referenced in the callback? Can you explain please? > Attached is a patch that fixes that issue. It also introduces a memory leak... Richard.
The following line from the gpm_brightness_init() function sets up a callback on gpm_brightness_filter_xevents: gdk_window_add_filter (window, gpm_brightness_filter_xevents, (gpointer) brightness); static GdkFilterReturn gpm_brightness_filter_xevents (GdkXEvent *xevent, GdkEvent *event, gpointer data) { GpmBrightness *brightness = GPM_BRIGHTNESS (data); if (event->type == GDK_NOTHING) return GDK_FILTER_CONTINUE; gpm_brightness_may_have_changed (brightness); return GDK_FILTER_CONTINUE; } As for the memory leak, sorry, I was getting lazy. I knew you'd review the code and thought the patch was the easiest way to communicate where the problem was. I'm not overly familiar with the code, so I'm not sure where the best place to place the call to unreference it. I figured that something that is only allocated ONCE per invocation of a program and only needs to be freed on process destruction (which frees ALL of a process's memory) isn't that serious of a memory leak. The provided fix is still much better than the segfault.
Created attachment 161423 [details] [review] test patch Does this patch also fix the segfault? Thanks.
After reverting my patch and confirming the presence of the segfault, I tried your "test patch". The segfault appears to be fixed with this patch.
Pushed to git master: commit 5e38f293308b0c1e85a9bd6b28ef13e29ba40817 Author: Richard Hughes <richard@hughsie.com> Date: Wed May 19 12:23:42 2010 +0100 Remove the filter in GpmBrightness to prevent a crash in some circumstances. Fixes #617529 Thanks Brian. :-)
Okay, with a fixed kernel it should all work as expected now with git master. Thanks everybody.
*** Bug 622361 has been marked as a duplicate of this bug. ***