Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Hello, On Thu, 30 Jan 2014, Michael Stapelberg wrote: At this point, I suggest taking this problem upstream. Either on the IRC channel, the mailing list, or the systemd bugtracker, it is much more likely to get good debugging ideas than here :). I took the problem upstream as suggested (#74629 on bugs.freedesktop.org). Lennart Poettering suggested various things but we still have not resolved the problem. Meanwhile, I installed the Debian package triggerhappy which has a daemon called thd which helped me diagnose the problem further. The Sleep Key on AOD 270 seems to be generating an event on /dev/input/event0 (Keyboard) and *no* event for the special Sleep Key event device /dev/input/event3. This can be seen by running thd --dump /dev/input/event3. It is not clear why this is so. Perhaps logind is misinformed by the kernel that Sleep events are being generated on /dev/input/event3? Or perhaps the kernel is not handling this particular laptop correctly. (Using a standard Debian kernel here.) Hope this helps in diagnosing the problem. Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Hi Kapil, kapil.iis...@gmail.com writes: It is not clear why this is so. Perhaps logind is misinformed by the kernel that Sleep events are being generated on /dev/input/event3? Or I’m not entirely sure where logind gets this information from. perhaps the kernel is not handling this particular laptop correctly. (Using a standard Debian kernel here.) Try booting the machine from a Fedora live medium or any other distribution to see whether you face the same troubles there. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Hi Kapil, Kapil Hari Paranjape ka...@imsc.res.in writes: As far as I can see the sleep key did not reach the logind daemon at all (it did not create any tracks in the trace)! However, the power key did. This seems to indicate that the problem is elsewhere. But where? I don’t know. At this point, I suggest taking this problem upstream. Either on the IRC channel, the mailing list, or the systemd bugtracker, it is much more likely to get good debugging ideas than here :). Thanks, and let us know when you figure it out. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Dear Michael, On Mon, 27 Jan 2014, Michael Stapelberg wrote: Kapil Hari Paranjape ka...@imsc.res.in writes: On Sun, 26 Jan 2014, Michael Stapelberg wrote: In fact, to test the setup, I did a debootstrap install of jessie, followed by installing systemd-sysv, the kernel and kbd. (In other words, a bare-bones install!) The showkey command still recognises the key as giving code 142 but suspend does not work. Can you please provide the output of the following command? Thanks for the info about how to debug this. I'm learning more about systemd (and the input system) through this investigation! for dev in /dev/input/event* do udevadm info -q all -n $dev done What you should see in there is a line saying TAGS=:power-switch:, which Attached. I see four instances of this tag. You should also see messages stating “Watching system buttons on /dev/input/event3 (Power Button)” in the journal, emitted by logind. Can you append the output of journalctl -u systemd-logind.service -b please? Attached. Similarly four instances of Watching system buttons are to be found. In particular, I do see that there is a watcher for the sleep button. Everything upto this point seems as it should be. In case this is not enough of a hint to debug and fix this, it’d also be good to provide a full strace output of logind (overwrite the ExecStart line to wrap logind in strace). I'll do this next. Regards, Kapil. -- P: /devices/platform/i8042/serio0/input/input0/event0 N: input/event0 S: input/by-path/platform-i8042-serio-0-event-kbd E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-0-event-kbd E: DEVNAME=/dev/input/event0 E: DEVPATH=/devices/platform/i8042/serio0/input/input0/event0 E: DMI_VENDOR=Acer E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_KEYBOARD=1 E: ID_PATH=platform-i8042-serio-0 E: ID_PATH_TAG=platform-i8042-serio-0 E: ID_SERIAL=noserial E: MAJOR=13 E: MINOR=64 E: SUBSYSTEM=input E: USEC_INITIALIZED=48537 P: /devices/platform/pcspkr/input/input5/event1 N: input/event1 S: input/by-path/platform-pcspkr-event-spkr E: DEVLINKS=/dev/input/by-path/platform-pcspkr-event-spkr E: DEVNAME=/dev/input/event1 E: DEVPATH=/devices/platform/pcspkr/input/input5/event1 E: ID_INPUT=1 E: ID_PATH=platform-pcspkr E: ID_PATH_TAG=platform-pcspkr E: ID_SERIAL=noserial E: MAJOR=13 E: MINOR=65 E: SUBSYSTEM=input E: USEC_INITIALIZED=54737 P: /devices/pci:00/:00:1b.0/input/input18/event10 N: input/event10 E: DEVNAME=/dev/input/event10 E: DEVPATH=/devices/pci:00/:00:1b.0/input/input18/event10 E: ID_INPUT=1 E: ID_PATH=pci-:00:1b.0 E: ID_PATH_TAG=pci-_00_1b_0 E: MAJOR=13 E: MINOR=74 E: SUBSYSTEM=input E: USEC_INITIALIZED=61193 P: /devices/pci:00/:00:1b.0/sound/card0/input21/event11 N: input/event11 E: DEVNAME=/dev/input/event11 E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/input21/event11 E: ID_INPUT=1 E: ID_PATH=pci-:00:1b.0 E: ID_PATH_TAG=pci-_00_1b_0 E: MAJOR=13 E: MINOR=75 E: SUBSYSTEM=input E: USEC_INITIALIZED=66340 P: /devices/pci:00/:00:1b.0/sound/card0/input20/event12 N: input/event12 E: DEVNAME=/dev/input/event12 E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/input20/event12 E: ID_INPUT=1 E: ID_PATH=pci-:00:1b.0 E: ID_PATH_TAG=pci-_00_1b_0 E: MAJOR=13 E: MINOR=76 E: SUBSYSTEM=input E: USEC_INITIALIZED=66562 P: /devices/pci:00/:00:1b.0/sound/card0/input19/event13 N: input/event13 E: DEVNAME=/dev/input/event13 E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/input19/event13 E: ID_INPUT=1 E: ID_PATH=pci-:00:1b.0 E: ID_PATH_TAG=pci-_00_1b_0 E: MAJOR=13 E: MINOR=77 E: SUBSYSTEM=input E: USEC_INITIALIZED=66802 P: /devices/pci:00/:00:1d.7/usb5/5-3/5-3:1.0/input/input6/event2 N: input/event2 S: input/by-id/usb-Chicony_Electronics_Co.__Ltd._WebCam-event-if00 S: input/by-path/pci-:00:1d.7-usb-0:3:1.0-event E: DEVLINKS=/dev/input/by-id/usb-Chicony_Electronics_Co.__Ltd._WebCam-event-if00 /dev/input/by-path/pci-:00:1d.7-usb-0:3:1.0-event E: DEVNAME=/dev/input/event2 E: DEVPATH=/devices/pci:00/:00:1d.7/usb5/5-3/5-3:1.0/input/input6/event2 E: ID_BUS=usb E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_MODEL=WebCam E: ID_MODEL_ENC=WebCam E: ID_MODEL_ID=b209 E: ID_PATH=pci-:00:1d.7-usb-0:3:1.0 E: ID_PATH_TAG=pci-_00_1d_7-usb-0_3_1_0 E: ID_REVISION=8257 E: ID_SERIAL=Chicony_Electronics_Co.__Ltd._WebCam E: ID_TYPE=video E: ID_USB_DRIVER=uvcvideo E: ID_USB_INTERFACES=:0e0100:0e0200: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=Chicony_Electronics_Co.__Ltd. E: ID_VENDOR_ENC=Chicony\x20Electronics\x20Co.\x2c\x20Ltd. E: ID_VENDOR_ID=04f2 E: MAJOR=13 E: MINOR=66 E: SUBSYSTEM=input E: USEC_INITIALIZED=79563 P: /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input9/event3 N: input/event3 E: DEVNAME=/dev/input/event3 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input9/event3 E: DMI_VENDOR=Acer E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-PNP0C0C:00 E: ID_PATH_TAG=acpi-PNP0C0C_00 E: MAJOR=13 E:
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Hi Kapil, Kapil Hari Paranjape ka...@imsc.res.in writes: On Sun, 26 Jan 2014, Michael Stapelberg wrote: $ journalctl -f -u systemd-logind.service Jan 26 11:19:28 x200 systemd-logind[11478]: Suspend key pressed. Jan 26 11:19:28 x200 systemd-logind[11478]: Suspending... I did not ever get this in the journal. In fact, to test the setup, I did a debootstrap install of jessie, followed by installing systemd-sysv, the kernel and kbd. (In other words, a bare-bones install!) The showkey command still recognises the key as giving code 142 but suspend does not work. I do not know where the problem lies. Perhaps systemd is relying on the event driver for the specific key and not the keyboard driver to generate the specific code (this is just a guess since I don't know much about this). I can investigate some more if you let me know what you want investigated. Can you please provide the output of the following command? for dev in /dev/input/event* do udevadm info -q all -n $dev done What you should see in there is a line saying TAGS=:power-switch:, which will make logind listen to that input device for system button events. You should also see messages stating “Watching system buttons on /dev/input/event3 (Power Button)” in the journal, emitted by logind. Can you append the output of journalctl -u systemd-logind.service -b please? In case this is not enough of a hint to debug and fix this, it’d also be good to provide a full strace output of logind (overwrite the ExecStart line to wrap logind in strace). -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Hi Kapil,
Kapil Hari Paranjape ka...@imsc.res.in writes:
It is possible that most users will not uninstall acpid and acpi-support
like I did. However, given that the sleep handling of that package will
interfere with the parallel handling by systemd, most online help
instructions suggest that users _disable_ ACPI_SLEEP and ACPI_SUSPEND from
/etc/default/acpi-support. At this point, the sleep key will again stop
working for them (at least on this laptop)!
I purged acpid and acpi-support{,-base} from my ThinkPad X200, then
restarted systemd-logind.service. When I press the suspend key, logind
will properly recognize that and suspend the machine:
$ journalctl -f -u systemd-logind.service
Jan 26 11:19:28 x200 systemd-logind[11478]: Suspend key pressed.
Jan 26 11:19:28 x200 systemd-logind[11478]: Suspending...
Jan 26 11:19:36 x200 systemd-logind[11478]: Operation finished.
Jan 26 11:19:36 x200 systemd-logind[11478]: New session c2 of user michael.
Jan 26 11:19:36 x200 systemd-logind[11478]: Removed session c2.
So, I conclude this is not a bug in (our packaging of) systemd/logind,
but rather most likely a configuration issue somewhere on your
machine. Perhaps there is yet another program that might grab/react to
this button? Also, did you try cold-booting your machine? On mine, after
you press the suspend key, the firmware is confused if no suspend
actually happens, i.e. further keypresses will not generate an event.
--
Best regards,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736389: [Pkg-systemd-maintainers] Bug#736389: systemd: HandleSuspendKey failes to handle sleep key
Dear Michael, On Sun, 26 Jan 2014, Michael Stapelberg wrote: $ journalctl -f -u systemd-logind.service Jan 26 11:19:28 x200 systemd-logind[11478]: Suspend key pressed. Jan 26 11:19:28 x200 systemd-logind[11478]: Suspending... I did not ever get this in the journal. In fact, to test the setup, I did a debootstrap install of jessie, followed by installing systemd-sysv, the kernel and kbd. (In other words, a bare-bones install!) The showkey command still recognises the key as giving code 142 but suspend does not work. I do not know where the problem lies. Perhaps systemd is relying on the event driver for the specific key and not the keyboard driver to generate the specific code (this is just a guess since I don't know much about this). I can investigate some more if you let me know what you want investigated. Regards, Kapil. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
