Bug 354841

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.

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.

*** Bug 405371 has been marked as a duplicate of this bug. ***

Also occurs on a Thinkpad X60, per bug 405371.

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.)

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..

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.

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.

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.

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.

FYI.. this is no longer happening in fedora10

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.

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

[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

Does this still happen with the version in fedora rawhide, or the version of the Fedora 11 beta live cd?

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.

(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.

This bug happens to me at least on Fedora 13, I will check with Fedora 14 later.