Bug 354841 - Removing power source from laptop causes suspend/sleep
Removing power source from laptop causes suspend/sleep
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
na
:
: 405371 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-26 16:27 EDT by wes hayutin
Modified: 2013-03-05 22:53 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-20 07:32:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2007-10-26 16:27:39 EDT
Description of problem:

recreate...
You may or may not have had to sleep the laptop one time prior...
1. remove power supply
results.. 
fedora 8 goes into sleep mode.. 

not sure what info you need...
hardware = IBM T43

[hayutin@localhost ~]$ cat /proc/acpi/ibm/driver 
driver:         ThinkPad ACPI Extras
version:        0.16
[hayutin@localhost ~]$ cat /proc/acpi/
ac_adapter/          event                processor/
alarm                fadt                 sleep
battery/             fan/                 thermal_zone/
button/              ibm/                 video/
dsdt                 info                 wakeup
embedded_controller/ power_resource/      
[hayutin@localhost ~]$ cat /proc/acpi/info 
version:                 20070126
Comment 1 Matthias Saou 2007-10-29 05:20:32 EDT
You probably didn't notice, but you filed this bug against powermanga, which is
a shoot-them-up game...
Please change it to the component you initially wanted, or it will never get
looked at.
Comment 2 Christoph Bachmaier 2007-11-20 08:04:59 EST
I have the same problem on my IBM ThinkPad T23. At the moment I assume it is
connected to the following setting in the gnome-power-manager preferences: 
On Battery Power -> When laptop lid is closed -> [Do Nothing/Blank
Screen/Suspend/Hibernate]
If I choose 'Do Nothing' and unplug the power cable, it does nothing (and doesen
suspend), if I put it on Blank Screen, it blanks the screen and if I put it on
Suspend it suspends after unplugging the power.
Comment 3 Bryan O'Sullivan 2007-11-29 23:58:03 EST
*** Bug 405371 has been marked as a duplicate of this bug. ***
Comment 4 Bryan O'Sullivan 2007-11-30 00:01:22 EST
Also occurs on a Thinkpad X60, per bug 405371.
Comment 5 Bryan O'Sullivan 2007-11-30 00:03:14 EST
gnome-power-manager-2.20.0-6.fc8.x86_64
hal-0.5.10-1.fc8.x86_64

(Editing summary to include word "suspend" to ease searches.)
Comment 6 wes hayutin 2007-11-30 08:25:35 EST
One note on this..
I'm wondering if the other people who have reproduced this bug upgraded to
fedora 8, as opposed to a fresh install of fedora 8.

After a fresh install of fedora 8, I no longer have this problem.
Thanks..
Comment 7 petrosyan 2007-11-30 08:31:37 EST
I did a fresh install of Fedora 8 on ThinkPad X61 and I also had this problem.
But it is not 100% reproducible. It happens after a few cycles of sleep/resume.
I don't know what exactly triggers it.
Comment 8 Mack Stanley 2007-12-12 22:37:48 EST
I have the same problem with a Toshiba M105-S3041 (core solo T1350; Intel 945GM
chipset). This is a fresh intallation of F8, updated recently:

kernel 2.6.23.8-63.fc8
gnome-power-manager 2.20.0
hal-0.5.10-1.fc8

acpid is off.

/var/log/messages shows nothing when it happens.

I have another gnome-power-manager problem.  Closing the lid triggers suspending
every other time. This may be a different bug, so I won't give details here
unless someone tells me to.
Comment 9 Julian Sikorski 2008-03-15 04:07:10 EDT
I am having similar issue with Toshiba Satellite A100-847. I thought that this
is a kernel bug, since I recently upgraded to kernel-2.6.24.3-12.fc8 and it
started to happen more often. It clearly seems it happens with older kernels as
well. My packages:
kernel-2.6.24.3-12.fc8.x86_64
hal-0.5.10-1.fc8.2.x86_64
gnome-power-manager-2.20.0-6.fc8.x86_64
/var/log/messages shows the following:
Suspending computer because the lid has been closed, and the ac adapter removed
(and gconf is okay)
The lid is definitely not closed when this happens. I'll try to reproduce this
bug somehow and post how to do it here.
Comment 10 Richard Hughes 2008-09-17 06:11:36 EDT
If the lid isn't closed when it happens, then please post "lshal -m" which is run before you remove the power lead when the lid is open. You shouldn't get lid events.
Comment 11 wes hayutin 2008-11-19 10:56:45 EST
FYI.. this is no longer happening in fedora10
Comment 12 Jason Farrell 2008-11-19 17:47:40 EST
FYI - this bug *is* reproducible in Fedora 10, and it's not comforting to see that I found this year old bug (with dupes) which still hasn't been assigned to anyone.

The problem appears to be due to the lid button state -- in "/proc/acpi/button/lid/LID0" here -- not getting through to HAL and gnome-power-manager. If I close the lid, then open the lid, then unplug the A/C, it'll go to sleep. Very annoying.

hal-0.5.12-12.20081027git.fc10.i386
gnome-power-manager-2.24.1-3.fc10.i386

To reproduce:
1) Default installation (updated)
2) Log in
3) Close lid
4) Open Lid
5) Unplug A/C

Actual Results:
Laptop goes to sleep when it obviously should not.

Additional Info:
I ran "lshal -m" while monitoring the actual button state in parallel, when doing: lid close, wait 5 seconds, lid open, remove A/C:

### lshal -m output. note that button.state.value does not return to false before A/C unplugged ###
Start monitoring devicelist:
-------------------------------------------------
17:35:47.736: computer_logicaldev_input_4 property button.state.value = true
17:35:47.747: computer_logicaldev_input_4 condition ButtonPressed = lid
17:36:27.523: computer_power_supply_ac_adapter_ACAD property ac_adapter.present = false
17:36:27.774: computer property power_management.is_powersave_set = true
17:36:28.198: computer_power_supply_battery_BAT1 property battery.voltage.current = 12434 (0x3092)

### actual lid button status at the same time ###
[guest@aao ~]$ while :; do echo -n "$(date) -- "; cat /proc/acpi/button/lid/LID0/state ; sleep 1 ; done
Wed Nov 19 17:35:45 EST 2008 -- state:      open
Wed Nov 19 17:35:46 EST 2008 -- state:      open
Wed Nov 19 17:35:47 EST 2008 -- state:      open
Wed Nov 19 17:35:48 EST 2008 -- state:      closed
Wed Nov 19 17:35:49 EST 2008 -- state:      closed
Wed Nov 19 17:35:50 EST 2008 -- state:      closed
Wed Nov 19 17:35:51 EST 2008 -- state:      closed
Wed Nov 19 17:35:52 EST 2008 -- state:      closed
Wed Nov 19 17:35:53 EST 2008 -- state:      closed
Wed Nov 19 17:35:54 EST 2008 -- state:      open
Wed Nov 19 17:35:55 EST 2008 -- state:      open
Wed Nov 19 17:35:56 EST 2008 -- state:      open
Wed Nov 19 17:35:57 EST 2008 -- state:      open


My smolt profile: http://smolts.org/show?uuid=pub_bbb797ed-9156-4880-ac9f-7f16013a9b79

Hope this helps. If it's still not enough info to get assigned & looked at, let me know what else I can provide. Thanks.
Comment 13 Bug Zapper 2008-11-25 21:02:27 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Julian Sikorski 2009-03-21 14:27:08 EDT
[jsikorski@snowball ~]$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
19:26:30.225: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = false
19:26:30.227: computer_power_supply_battery_BAT0 property battery.remaining_time = 3431 (0xd67)
19:26:30.228: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 95 (0x5f)
19:26:30.230: computer_power_supply_battery_BAT0 property battery.charge_level.current = 3675 (0xe5b)
19:26:30.231: computer_power_supply_battery_BAT0 property battery.reporting.current = 245 (0xf5)
19:26:30.232: computer_power_supply_battery_BAT0 property battery.rechargeable.is_discharging = true
19:26:30.233: computer_power_supply_battery_BAT0 property battery.rechargeable.is_charging = false
19:26:30.488: computer property power_management.is_powersave_set = true
19:26:51.194: computer_power_supply_battery_BAT0 property battery.remaining_time = 112 (0x70)
19:26:51.209: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 93 (0x5d)
19:26:51.212: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 7710 (0x1e1e)
19:26:51.213: computer_power_supply_battery_BAT0 property battery.charge_level.current = 3600 (0xe10)
19:26:51.213: computer_power_supply_battery_BAT0 property battery.reporting.current = 240 (0xf0)
19:26:51.222: computer_power_supply_battery_BAT0 property battery.rechargeable.is_discharging = false
19:26:51.231: computer_power_supply_battery_BAT0 property battery.rechargeable.is_charging = true
19:26:51.235: computer_power_supply_battery_BAT0 property battery.reporting.rate = 514 (0x202)
19:26:51.236: ieee1394_guid80da0d161e96c removed
19:26:51.236: ieee1394_guid80da0d161e96c added
19:26:51.236: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = true
19:26:57.486: computer property power_management.is_powersave_set = false
Comment 15 Richard Hughes 2009-04-15 11:52:21 EDT
Does this still happen with the version in fedora rawhide, or the version of the Fedora 11 beta live cd?
Comment 16 Jason Farrell 2009-04-15 12:51:22 EDT
I am no longer able to reproduce this bug (comment #12 above) using F11 snap1 on the same netbook. Also good to see the on-battery/off-battery notification happening much quicker.
Comment 17 Richard Hughes 2009-08-20 07:32:46 EDT
(In reply to comment #16)
> I am no longer able to reproduce this bug (comment #12 above) using F11 snap1
> on the same netbook. Also good to see the on-battery/off-battery notification
> happening much quicker.  

Cool, thanks.
Comment 18 Pavel Šimerda (pavlix) 2011-01-23 10:54:23 EST
This bug happens to me at least on Fedora 13, I will check with Fedora 14 later.

Note You need to log in before you can comment on or make changes to this bug.