touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

This happens around the time when this fires:

Breakpoint 1, manager_handle_action (m=0x555555616010, inhibit_key=INHIBIT_HANDLE_LID_SWITCH, handle=HANDLE_IGNORE, 
    ignore_inhibited=true, is_edge=false) at src/login/logind-action.c:36
36	in src/login/logind-action.c

(gdb) bt full
#0  manager_handle_action (m=0x555555616010, inhibit_key=INHIBIT_HANDLE_LID_SWITCH, handle=HANDLE_IGNORE, ignore_inhibited=true, 
    is_edge=false) at src/login/logind-action.c:36
        message_table = {0x0, 0x5555555e8f9c "Powering Off...", 0x5555555e8fac "Rebooting...", 0x5555555e8fb9 "Halting...", 
          0x5555555e8fc4 "Rebooting via kexec...", 0x5555555e8fdb "Suspending...", 0x5555555e8fe9 "Hibernating...", 
          0x5555555e8ff8 "Hibernating and suspending...", 0x0}
        target_table = {0x0, 0x5555555e9016 "poweroff.target", 0x5555555e9026 "reboot.target", 0x5555555e9034 "halt.target", 
          0x5555555e9040 "kexec.target", 0x5555555e904d "suspend.target", 0x5555555e905c "hibernate.target", 
          0x5555555e906d "hybrid-sleep.target", 0x0}
        error = {name = 0x7fffffffe440 "p\344\377\377\377\177", 
          message = 0x555555565aba <manager_is_docked_or_multiple_displays+162> "\211E\354\203", <incomplete sequence \354>, 
          _need_free = -7120}
        inhibit_operation = 1432480080
        offending = 0x90a9bdd80dca0d00
        supported = false
        r = 21845
        __PRETTY_FUNCTION__ = "manager_handle_action"
        __func__ = "manager_handle_action"
#1  0x0000555555566572 in button_lid_switch_handle_action (manager=0x555555616010, is_edge=false)
    at src/login/logind-button.c:108
        handle_action = HANDLE_IGNORE
        __PRETTY_FUNCTION__ = "button_lid_switch_handle_action"
#2  0x0000555555566601 in button_recheck (e=0x555555621420, userdata=0x555555625e40) at src/login/logind-button.c:117
        b = 0x555555625e40
        __PRETTY_FUNCTION__ = "button_recheck"
#3  0x00005555555b837b in source_dispatch (s=0x555555621420) at src/libsystemd/sd-event/sd-event.c:2150
        r = 0
        __PRETTY_FUNCTION__ = "source_dispatch"
        __func__ = "source_dispatch"
#4  0x00005555555b968d in sd_event_dispatch (e=0x555555617210) at src/libsystemd/sd-event/sd-event.c:2471
        p = 0x555555621420
        r = 0
        __PRETTY_FUNCTION__ = "sd_event_dispatch"
#5  0x00005555555b97ec in sd_event_run (e=0x555555617210, timeout=18446744073709551615)
    at src/libsystemd/sd-event/sd-event.c:2494
        r = 1
        __PRETTY_FUNCTION__ = "sd_event_run"
#6  0x0000555555563cac in manager_run (m=0x555555616010) at src/login/logind.c:1117
        us = 18446744073709551615
        r = 0
        __PRETTY_FUNCTION__ = "manager_run"
#7  0x0000555555563f96 in main (argc=1, argv=0x7fffffffe6d8) at src/login/logind.c:1179
        m = 0x555555616010
        r = 0
        __func__ = "main"

The is_edge==false is interesting, which proves that it's not coming
from logind-button.c's button_dispatch(). This is consistent with evtest
not getting any event.

button_check_switches() apparently detects that the lid is detected as
closed (note: this machine doesn't actually have a lid). Then
button_install_check_event_source() fires off an idle handler which
repeatedly checks for the button state. Apparently something makes too
strong or wrong assumptions there, I'll keep digging.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1438301

Title:
  desktop machine suspends with systemd after ~3 minutes, does NOT
  suspend with upstart

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  For reasons I cannot fathom, my development server goes into deep
  suspend after ~3 minutes after startup with systemd, however, if I
  boot with upstart it does not.   This happens everytime I boot with
  systemd, the machine just goes into a deep suspend without me
  requesting it.

  I enabled "debug"; attached is a gzip'd syslog showing the activity -
  look at the end of the log, it goes into deep suspend. No idea why.

  acpi_listen is showing some curious audio plug/unplug events that seem
  to occur on this development box, so maybe these are being
  misinterpreted as suspend events.

  $ acpi_listen
  jack/headphone HEADPHONE plug
  jack/headphone HEADPHONE unplug
  jack/headphone HEADPHONE plug
  jack/headphone HEADPHONE unplug
  jack/headphone HEADPHONE plug
  jack/headphone HEADPHONE unplug

  ..but I am not seeing any other ACPI related events that could be
  triggering a suspend request from acpi_listen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438301/+subscriptions