Laptop suspends when I connect/disconnect AC

I'm experiencing the same bug in a Acer Aspire One D150. How can I help to debug this issue?

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please open a terminal and execute: apport-collect 481312 ? It will attach the necessary information to this report. Also you can submit more information for it by looking to https://wiki.ubuntu.com/DebuggingGNOMEPowerManager , Thanks in advance.

Architecture: i386
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: gnome-power-manager 2.28.1-0ubuntu1
PackageArchitecture: i386
ProcEnviron:
 PATH=(custom, no user)
 LANG=es_PE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
Uname: Linux 2.6.31-17-generic i686
UserGroups:

XsessionErrors:
 (gnome-settings-daemon:1579): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:1619): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:1640): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-power-manager:1635): Gdk-CRITICAL **: gdk_window_thaw_toplevel_updates_libgtk_only: assertion `private->update_and_descendants_freeze_count > 0' failed

Architecture: i386
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-power-manager 2.28.1-0ubuntu1
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_GB.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
Uname: Linux 2.6.31-15-generic i686
UserGroups: adm admin audio cdrom dialout dip fax fuse lpadmin mythtv netdev plugdev sambashare scanner tape video

I'm not the bug publisher, but this bug really annoys me, so I posted my Acer Aspire One D150 data here, hth.

Thank you!

Architecture: i386
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: gnome-power-manager 2.28.1-0ubuntu1.3
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-19.56-generic
Uname: Linux 2.6.31-19-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
 (gnome-settings-daemon:1405): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:1405): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:1443): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:1457): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (firefox-bin:2039): GLib-WARNING **: g_set_prgname() called multiple times

Happens on a Sony Vaio W.

The following Ubuntu Wiki says it's easily fixed, but it doesn't say how...
https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks#Sony VAIO W

Apport connect seems to hang (proxy issue?) so I'll attach .txt files manually...

I have similar problem.
My Toshiba A205 freezes when I switch the power from AC to battery on Lucid and Karmic.
I've tried to run live Knoppix with kernel 2.6.32 but it doesn't work. I did the same with live Hardy 2.6.24 and it works perfect.
 http://ubuntuforums.org/showthread.php?p=9039341#post9039341

This bug is still an issue as of Ubuntu Lucid beta 2. I will run the apport-collect command to get additional info.

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Ubuntu 10.04 w/ all updates as of 4/12/10 (including 2.6.32-20 kernel)

Never mind; I will only do so if asked.

/proc/acpi/button/lid/LID/state reports closed when it should report open

FYI this bug prevails in Lucid Lynx

This is probably a duplicate of bug 531190, so I'm marking as such. Thanks for the report!

I'm sorry, maybe I was being overzealous. Does gnome-power-manager warn you about critically low battery before it suspends? If so, then it is a duplicate.

@David there is no warning (at least in my AOD150) when I connect/disconnect AC, it just suspends. I think this bug looks similar to #421985.

Oliver: Thanks for the feedback. Indeed it's similar to bug 421985, but he doesn't mention suspend when /plugging in/ AC there. What happens if you run "killall gnome-power-manager" first? Will the laptop still suspend?

David,

I just tested it, As we all expected, the laptop doesn't suspend with I kill the "gnome-power-manager" first and then plug/unplug :-)

Thanks, that's pretty weird that it's not telling you critical battery before suspending. Could you follow the instructions at <https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#Getting%20DBUS%20info> to see which power management events your system is seeing when you plug in and unplug? Please attach the results here. Thanks!

Here's a dbus log.

If I run interface='org.freedesktop.PowerManagement' I get nothing. So I've attached my entire dbus log with the Jabber usernames sanitised.

It only seems to happen the first time I connect A/C. Probably because afterwards it thinks the lid is closed.

Full dbus log

Berend: very weird. Does the issue persist for you as well if you kill g-p-m?

If I kill gnome-power-manager it does not happen.

Without gnome-power-manager:
1. boot without a/c
2. login
3. plug in a/c
4. screen stays dim, does not suspend. No popups.

with gnome-power-manager
1. boot without a/c
2. login
3. plug in a/c
4. screen goes bright
4a. popup (battery charging; will take X minutes) (sometimes too slow)
5. suspends (takes a minute)
6. type on keyboard
7. un-suspends
8. screen is locked by screensaver

Further a/c connect/disconnect:
* no suspend.
* popups about battery charging working as expected.
* The screen does not dim.

The desktop knows the cable is unplugged, because I get popups, but it doesn't take any action. When battery power gets very low it shuts down.

The suspends are immediate. This is annoying when you've got powercuts or accidentally trip the cable.

Once the A/C disconnect/reconnect has cycled, I can kill and restart gnome-power-manager, and the laptop does not suspend.

btw, if I kill gnome-power-manager, and run it as root (i.e. sudo), it runs perfectly.

-- scratch that last, I found the power button doesn't show the Shutdown window when I run g-p-m as root.

Ahah, Berend I didn't see your comment about lid state before. What happens if you change the "Lid Closed" action in g-p-m to Nothing (or Blank Screen or whatever it says)?

Also, please post the results of "upower -d | grep lid" (on Lucid, or "devkit-power -d | grep lid" on Karmic) for the following conditions:

1) Immediately after boot.
2) If possible, between plugging in AC (after notification) and the suspend.
3) After resume.

If possible, please reproduce this information on Lucid or even Maverick, just to make sure we're using the latest available versions.

This is all for Lucid:

The lid is always closed. /proc/acpi/button/lid/LID/state is always closed. upower -d | grep lid always looks like:
  lid-is-closed: yes
  lid-is-present: yes

I find that very interesting.

If I set g-p-m to blank screen (choices [ blank | suspend | hibernate | shutdown ]) it blanks the screen.

I then ran upower -d in an infinite loop, and ran diff on the results. Here's the results:

chunk.315 -- just before plugin
chunk.316 -- at plugin

chunk.diff -- the whole diff.

chunk.0 was empty. chunk.325 was also empty (during suspend)

The stuff that changes:
state: discharging -> charging
on-battery: yes -> no
energy rate
percentage
time to empty / time to full

Ahah, I think we've found the underlying problem thanks to your help, then. :)

I'm not quite sure why g-p-m only performs its lid-close operation when you plug/unplug, though. Can you perform the steps at <https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#Getting%20info%20from%20g-p-m> and attach the log here?

OK, attached.

I'd guess lid_state is an uninitialised variable. I can't get the source from behind the proxy.

Line: action: /apps/gnome-power-manager/buttons/lid_ac set to suspend (The lid has been closed on ac power.)

gpm-button.c/gpm_button_client_changed_cb() compares

        if (button->priv->lid_is_closed == lid_is_closed)
                return;

gpm-button.c/gpm_button_class_init() adds struct GpmButtonPrivate but I can't find an equivalent of

        /* coldplug so we are in the correct state at startup */
        g_object_get (manager->priv->client,
                      "on-battery", &manager->priv->on_battery,
                      NULL);

You can try the following patch.

I can't apt-get -b source right now, so I can't test.

Hi Berend, thanks for the log! Pinpointed the problem.

You're right that the problem is with lid_is_closed, but your patch isn't quite right. "lid-is-closed" is a property provided by upower and we can't modify it. The issue is that g-p-m /assumes/ the lid is open when it starts up, so the next time it notices that it's closed, it does the lid closed action. I'll work on a new patch.

Anyone affected by the bug, please try my gnome-power-manager build in my PPA at <https://launchpad.net/~dgtombs/+archive/ppa>. Thanks!

On second thought, don't install the PPA version yet, I made a mistake in the version numbering. I'll re-upload soon.

OK, re-uploaded new packages with correct version numbers.

@David I just install your g-p-m (2.30.0-0ubuntu1ppa1) and tried the plug/unplug thing, and my laptop still acts like I close the lid :( I have, as Berend said (#40), my lid status always as close:

drmad@hellboy:~$ cat /proc/acpi/button/lid/LID0/state
state: closed
drmad@hellboy:~$ upower -d | grep lid
  lid-is-closed: yes
  lid-is-present: yes

btw the lid action never worked since 9.10 IIRC

The updated package doesn't work for me either. On my system, if I unplug the AC soon after booting up, it doesn't trigger the lid-closed event. However, if I close and open the lid, then trying to unplug the AC afterward will trigger the lid-close event. The lid-closed event will still sometimes be triggered by unplugging the AC cord even if I haven't closed the lid--just not right after booting up. This behavior was present with the previous version of gnome-power-manager and hasn't changed at all with the updated package (2.30.0-0ubuntu1ppa1).

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Ubuntu 10.04 i386 w/ all updates as of 6/19/2010 (including 2.6.32-22 kernel)

I tried the wrong version numbered one. (bad timing, download, dpkg -i), and now I had the exact opposite happen:

The first time, nothing happens (not even popups saying charging)

The second time, and all subsequent times: suspend.

My patched version should only have the following effect: when you plug in the machine, it should not execute the lid-closed action. It will probably still execute it when you unplug it (which is not really a bug in g-p-m, it's a bug in upower). So you all are saying that plugging it in still always results in lid-close action anyway? If so, I'll have to modify my patch to include more logging to figure out what's going wrong I guess.

Berend: sorry about the version issue. The problem is that my version # was the same as the next one to be released by Ubuntu. You can do a force-downgrade, the package manager will warn you it's dangerous but in this case it should do no harm.

@Oliver I have a D150 also and had the same problem you are having until today. I just flashed a new BIOS (v1.13) and that seems to have fixed the issue of the netbook suspending when I disconnect the AC power.

David, on my system, the lid-closed event only triggers when I unplug the power, at the same instant the "Battery Charging" notification appears". When I plug the power back in, it acts as it should (screen gets brighter, no lid-closed event triggered).

So, if your patch was to address the lid-closed event on power connect, then it seems to be fixed with your package on my system. It's just the power-disconnect that seems to be the problem (which you mentioned was upower's fault).

@Scott WOW! :-D Thank you for the advice!!!! Now "lid-is-close" is "no", and changes when I actually close the lid! Also, the processor is now running at 1.66 GHz :-D

i'm so happy :-D

I'm adding a new gpm.log.

It triggers lid_battery set to suspend (The lid has been closed, and the ac adapter removed (and gconf is okay).)

So if I've got this right I need to file a feature request with the upower package to please ignore broken lids.

gpm-manager in gpm_manager_client_changed_cb() sometimes checks for on_battery, and sometimes checks for on_battery && lid_is_closed.

This patch makes it consistent (always check for on_battery && lid_is_closed)

Again: untested, sorry

If this works, I'd like to get a little help with logging the feature request correctly to upower (or kernel acpi) assuming it's a bios bug.

Noticed it's marked as affecting upower already.

Scott, Oliver: glad it worked out for you!

Chris Collins: thanks for the report. I'll mention that upstream.

Berend: your patch will work around the issue for your laptop, but it breaks functionality in g-p-m for working laptops so unfortunately it's not going to get put into the release. Since this has been shown to be hardware-dependent, I think we should split this report into hard-ware specific reports. Would you mind filing a new report with "ubuntu-bug upower" from Lucid? Please be clear about your specific laptop model in the new report, and post the new bug # in here.

Thanks all for your patience.

I've reported # 597963 for upower.

Marking Triaged. David, any idea of when we will have it? Still in Maverick?

The commit is <http://git.gnome.org/browse/gnome-power-manager/commit/?id=df44925b580ff0aa4a4f0619f3d50987c939506d> and no, it's not in maverick yet.

David, should I file a new bug report for my specific hardware as well? (HP Pavilion dv1550se laptop)

s-chriscollins: yes, please file a new report. It's better to have multiple, duplicate reports than one mixed report. Thank you!

Hi David. I had already filed a bug (bug #561656), but it was under gnome-power-manager, so I have changed it to upower instead. Please let me know if there is any more information I can provide.

Unfortunately a lot of BIOSes are broken and report a wrong lid status. The only reliable method of knowing the lid status is seeing it changing, so we shouldn't make g-p-m depend on the initially reported lid status. There's unfortunately not a lot upower could do about it.

Pulled patch into packaging branch.

This bug was fixed in the package gnome-power-manager - 2.30.1-1ubuntu3

---------------
gnome-power-manager (2.30.1-1ubuntu3) maverick; urgency=low

  [ Martin Pitt ]
  * Add 00git-initial-lid-status.patch: Do not assume the lid is open at
    boot. (LP: #481312)
  * debian/rules: Switch to --disable-hal, and drop hal Suggests in
    debian/control.in.

  [ Alberto Milone ]
  * Add 00git-kernel-backlight-interface.patch:
    - Backport PolicyKit code to access the kernel backlight interface
      so as to be able to use dim the backlight without hal also when the
      backlight is not exposed as an RandR property (e.g. in the radeon
      driver).
 -- Martin Pitt <email address hidden> Fri, 30 Jul 2010 18:42:57 +0200

And now, what can I do to fix my gpm on UNR 10.02? Is there an update / fix for my system that I can download or an other solution yet?

Sorry, but there's no update. You can try the workaround listed in the description.

I have this problem. Running Ubuntu 10.10 on Dell Inspiron 700m. gnome-power-manager version is at version 2.32.0-0ubuntu1.

dkandz@dkandz-Inspiron-700m:/var/log$ upower -d | grep lid
  lid-is-closed: yes
  lid-is-present: yes
dkandz@dkandz-Inspiron-700m:/var/log$
 (of course, my laptop lid was open)

The workaround works, but it would be nice if new Ubuntu users (like myself) did not have to experience the problem, or discover the solution.

What can I do to help?

Thanks!

Hi Dave, I think your best bet is to contact Dell and let them know the problem. It's their BIOS that is broken. Not a great answer, I know, but we don't have any other choice.