unplugging AC-power triggers "lid is closed" event

Bug #585601 reported by Christian Göbel
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: upower / devicekit-power

Since I am using Ubuntu Lucid (10.04) I have the following issue on my 4 year old Samsung x20 Laptop:
Whenever I unplug the AC-power cable the laptop triggers the "lid is closed" event.

For example, if I change the preferences in "Power Management Preferences" in the tab "On Battery Power" the option for "When laptop lid is closed" to e.g. "Blank screen" - then the screen will blank when unplugging. When I set this option to "Suspend", then the laptop will suspend.

I did not suffer from anything similar in the past - so this is a regression in Lucid.
Reporting the bug against UPower/devicekit-power but maybe this is a gpm-issue - feel free to reassign.
If I can provide further information, please let me know. How can this be debugged?

---
Architecture: i386
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100213)
Package: upower 0.9.1-1
PackageArchitecture: i386
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-22.34~kms1-generic 2.6.32.11+drm33.2
Tags: lucid
Uname: Linux 2.6.32-22-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Christian Göbel (christiangoebel) wrote : Dependencies.txt

apport information

description: updated
affects: devicekit-power (Ubuntu) → upower (Ubuntu)
tags: added: apport-collected
description: updated
tags: added: regression-potential
summary: - (un)-plugging AC-power triggers suspend
+ unplugging AC-power triggers "lid is closed" event
description: updated
Erik Meitner (e.meitner)
affects: upower (Ubuntu) → acpi-support (Ubuntu)
Revision history for this message
Erik Meitner (e.meitner) wrote :

Open a terminal(Applications->Accessories->Terminal), type the following and press enter: lshal -m
Then unplug,wait, and then insert the AC cord. Paste the results here.

Still in the Terminal, type CTRL-C. Then enter the following and press enter: sudo acpi_listen
Again, unplug AC,wait, and then insert the AC cord.Paste the results here.

Revision history for this message
Steve Langasek (vorlon) wrote :

lshal -m is not relevant. We don't use hal for anything by default in 10.04.

We do need to see the output of 'acpi_listen'.

Changed in acpi-support (Ubuntu):
status: New → Incomplete
Revision history for this message
Christian Göbel (christiangoebel) wrote :

Here is the output from acpi_listen:
The only thing I do is first unplugging than I wait some second and I plug the AC-power in again.
As described above, the screen blanks (as if I closed my laptop lid), when I plug the AC-power in again,
nothing happens. (The screen stays blank - but I can wake it up by pressing any key)

~$ sudo acpi_listen
[sudo] password for xxx:
ac_adapter ADP1 00000080 00000000
processor CPU0 00000081 00000000
ac_adapter ADP1 00000080 00000001
processor CPU0 00000081 00000000

Further observation: When the the screen is blanked, I can also wake it up by pressing any
key on my keyboard even with unplugged AC-power - however in this case the screen wakes up dimmed.

By the way - if I close the lid of my laptop, then acpi_listen does not show any output.
I hope this is helpful. Please let me know if you want me to check anything else.

Revision history for this message
Christian Göbel (christiangoebel) wrote :

By the way, hal 0.5.14-0ubuntu6 is installed on my system. Not sure if that has any meaning for the reported issue.

Revision history for this message
Steve Langasek (vorlon) wrote :

Ok, none of the acpi_listen output here would trigger acpi-support to generate a "lid closed" event. Reassigning this bug to the udev package, which is the next most likely candidate.

Please read the section on "Fixing broken keys" in /usr/share/doc/udev/README.keymap.txt.gz for information on how to verify that your keymap is correct. It may be that pressing this hotkey is being mapped to a wrong keysym here.

affects: acpi-support (Ubuntu) → udev (Ubuntu)
Revision history for this message
Christian Göbel (christiangoebel) wrote :

That is how far I get when trying to debug udev:

~$ /lib/udev/findkeyboards
AT keyboard: input/event5

~$ sudo /lib/udev/keymap -i input/event5

Now the cursor runs down the terminal probably waiting for key-strokes. (By the way how can this be stopped properly?)
Any keystroke on my keyboard seems to print the corresponding "scan code" in the terminal - lines are moving too fast for reading it but there is some output.
However if I close my lid or if I unplug my AC-power then no "scan code" is printed in the terminal.

I guess I am missing something here. Sorry, this is all new to me. Any hints?

Revision history for this message
Hajo Nils Krabbenhöft (fxtentacle) wrote :

Hi

i'm facing this exact same problems on an Samsung X20 XVM 1730 III.

# lshal -m

Start monitoring devicelist:
-------------------------------------------------

12:18:57.005: computer_power_supply_battery_BAT1 property battery.remaining_time = 2048 (0x800)
12:18:57.007: computer_power_supply_battery_BAT1 property battery.charge_level.rate = 35187 (0x8973)
12:18:57.010: computer_power_supply_battery_BAT1 property battery.reporting.rate = 3170 (0xc62)
<plug in power cord>
12:19:00.592: computer_power_supply_ac_adapter_ADP1 property ac_adapter.present = true
12:19:03.671: computer_power_supply_battery_BAT1 property battery.remaining_time = 859 (0x35b)
12:19:03.672: computer_power_supply_battery_BAT1 property battery.charge_level.rate = 18403 (0x47e3)
12:19:03.673: computer_power_supply_battery_BAT1 property battery.rechargeable.is_discharging = false
12:19:03.675: computer_power_supply_battery_BAT1 property battery.rechargeable.is_charging = true
12:19:03.676: computer_power_supply_battery_BAT1 property battery.reporting.rate = 1658 (0x67a)
12:19:03.677: computer_power_supply_battery_BAT1 property battery.voltage.current = 11974 (0x2ec6)
<remove power cord>
12:19:09.299: computer_power_supply_ac_adapter_ADP1 property ac_adapter.present = false

# acpi_listen
battery BAT1 00000080 00000001
<plug in power cord>
ac_adapter ADP1 00000080 00000001
processor CPU0 00000081 00000000
battery BAT1 00000080 00000001
<remove power cord>
ac_adapter ADP1 00000080 00000000
processor CPU0 00000081 00000000

So i suppose power cord events work fine for both lshal and acpi_listen.

Revision history for this message
Hajo Nils Krabbenhöft (fxtentacle) wrote :

cat /proc/acpi/button/lid/*/*
type: Lid Switch
state: closed

udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_3'
  button.has_state = true (bool)
  button.state.value = true (bool)
  button.type = 'lid' (string)
  info.addons.singleton = {'hald-addon-input'} (string list)
  info.capabilities = {'input', 'input.switch', 'button'} (string list)
  info.category = 'input' (string)
  info.parent = '/org/freedesktop/Hal/devices/computer' (string)
  info.product = 'Lid Switch' (string)
  info.subsystem = 'input' (string)
  info.udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_3' (string)
  input.device = '/dev/input/event0' (string)
  input.product = 'Lid Switch' (string)
  linux.device_file = '/dev/input/event0' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'input' (string)
  linux.sysfs_path = '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0/event0' (string)

-> so both methods think the lid is closed, while its open.

both acpi_listen and lshal -m do not show any messages when i close / open the lid

Revision history for this message
Hajo Nils Krabbenhöft (fxtentacle) wrote :

/lib/udev/keymap -i input/event5

does not print any key codes for
- sleep button
- power button
- a/c add&remove
- lid open&close

I'm happy with compiling a custom kernel, i've developed mac&windows kernel driver and i'd like to look into this issue.
However, i could use some guidance on where to start searching, as i haven't done much linux kernel / driver development lately.

Revision history for this message
Hajo Nils Krabbenhöft (fxtentacle) wrote :
Download full text (3.8 KiB)

I just checked with udevadm monitor, and to me it looks as if udev receives the power cord events correctly:

# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1277980838.924991] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
KERNEL[1277980838.925064] remove /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
KERNEL[1277980838.925111] remove /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
KERNEL[1277980838.925157] remove /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
KERNEL[1277980838.925201] remove /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
KERNEL[1277980838.925245] add /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
KERNEL[1277980838.925292] add /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
KERNEL[1277980838.925336] add /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
KERNEL[1277980838.925380] add /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
KERNEL[1277980838.925426] add /devices/system/cpu/cpu0/cpuidle/state4 (cpu)
UDEV [1277980838.932830] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [1277980838.932897] remove /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
UDEV [1277980838.934523] add /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
UDEV [1277980838.946447] add /devices/system/cpu/cpu0/cpuidle/state4 (cpu)
UDEV [1277980838.948045] remove /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
UDEV [1277980838.949262] add /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
UDEV [1277980838.950746] remove /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
UDEV [1277980838.951963] add /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
UDEV [1277980838.955468] remove /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
UDEV [1277980838.955529] add /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
KERNEL[1277980845.590555] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
KERNEL[1277980845.590599] remove /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
KERNEL[1277980845.590621] remove /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
KERNEL[1277980845.590643] remove /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
KERNEL[1277980845.590664] remove /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
KERNEL[1277980845.590685] remove /devices/system/cpu/cpu0/cpuidle/state4 (cpu)
KERNEL[1277980845.590706] add /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
KERNEL[1277980845.590727] add /devices/system/cpu/cpu0/cpuidle/state1 (cpu)
KERNEL[1277980845.590748] add /devices/system/cpu/cpu0/cpuidle/state2 (cpu)
KERNEL[1277980845.590769] add /devices/system/cpu/cpu0/cpuidle/state3 (cpu)
UDEV [1277980845.594969] change /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV [1277980845.595007] remove /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
UDEV [1277980845.595666] add /devices/system/cpu/cpu0/cpuidle/state0 (cpu)
UDEV [1277980845.601848] remove /devices/system/cpu/cpu0/cpuidle/state4 (cpu)
UDEV [1277980845.602750] remove /devices/system/cpu/cpu...

Read more...

Revision history for this message
Hajo Nils Krabbenhöft (fxtentacle) wrote :

From /var/log/syslog

Pressing power key:
Jul 1 12:49:28 kathrin-laptop udevd[296]: seq 1788 queued, 'change' 'power_supply'
Jul 1 12:49:28 kathrin-laptop udevd[296]: passed 553 bytes to monitor 0x20e771f0
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: seq 1788 running
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: device 0x20e82178 has devpath '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00'
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: device 0x20e82730 has devpath '/devices/LNXSYSTM:00/LNXSYBUS:00'
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: device 0x20e83208 has devpath '/devices/LNXSYSTM:00'
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: RUN 'socket:@/org/freedesktop/hal/udev_event' /lib/udev/rules.d/90-hal.rules:2
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: passed 590 bytes to monitor 0x20e83378
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: passed -1 bytes to monitor 0x20e823c8
Jul 1 12:49:28 kathrin-laptop udevd-work[31860]: seq 1788 processed with 0
Jul 1 12:49:28 kathrin-laptop udevd[296]: seq 1788 done with 0

Closing or opening the lid does not give any udev events.

I attached a part of my syslog which shows the udev events generated when i unplug and then re-plug the power cord.

Revision history for this message
Steve Langasek (vorlon) wrote :

> $ cat /proc/acpi/button/lid/*/*
> type: Lid Switch
> state: closed

> -> so both methods think the lid is closed, while its open.

Ok, then this is a kernel problem, not a udev problem.

> both acpi_listen and lshal -m do not show any messages when i close / open the lid

There is probably an event on a different input device than the keyboard. You can check the full set of input devices on your system by running 'sudo lsinput' from the input-utils package.

affects: udev (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → New
Revision history for this message
Christian Göbel (christiangoebel) wrote :

I set the bug status to "confirmed" since Hajo Nils confirmed the issue.
Steve Langasek has suggested that this is likely to be a kernel problem.

Any hints on how this kernel problem could be debugged properly?

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Christian Göbel (christiangoebel) wrote :

The reported problem seems to be fixed in Ubuntu 10.10.
I cannot reproduce anymore. Thanks a lot for fixing.
As the original reporter of the bug I will close the bug - feel free to open again if the problem still exists for you.

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Christian Göbel (christiangoebel) wrote :

I am reopening this bug since the issue hit me again.
When I tried to reproduce the bug I didn't succeed, however. So something
got fixed in the meanwhile but under certain circumstances the bug
is still there.
:-/

Changed in linux (Ubuntu):
status: Fix Released → New
Revision history for this message
Christian Göbel (christiangoebel) wrote :

After several months of testing Ubuntu 10.10. I now understand better why the issue reported here cannot be reproduced reliably.

In Ubuntu 10.04 the following issue appeared (reported above):
- unplugging the power plug always triggers the lid-closed event.

In Ubuntu 10.10 the following issue appeared in addition:
- closing lid event does not work reliable any-more on my computer
  In roughly 50% of the cases, closing the lid will NOT suspend my computer - in 50% it works.

I conclude that unplugging the power plug still seems to trigger the lid-closed event. As a result of the new
issue, however this has no effect in 50% of the cases.

So it seems that a new bug (lid-closed event is not reliable) led to a situation where the original issue reported above cannot be reproduced reliably, any more.

Any suggestions on how to debug this issue?

tags: removed: regression-potential
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 585601

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: lucid
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.