Bug 193841

Summary:	Kernel Not Handling SysRqs When Wayland Servers Freeze
Product:	Drivers	Reporter:	Antoine Saroufim (antoine.saroufim)
Component:	Input Devices	Assignee:	drivers_input-devices
Status:	NEW ---
Severity:	high	CC:	dmitry.torokhov, linux-kernel, peter.hutterer, toomaskaevand
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	4.9.6	Subsystem:
Regression:	No	Bisected commit-id:

Description Antoine Saroufim 2017-02-02 17:13:25 UTC

I initially reported this issue at the Freedesktop Bugzilla and was told to file a bug report against the kernel https://bugs.freedesktop.org/show_bug.cgi?id=99645

When using Wayland/KMS servers such as gnome-wayland and retroarch (standalone) on a system with libinput 1.6.0 and systemd 232-8, the system stops responding to SysRq if the client freezes. The input would be totally dead. Pressing num lock for instance wouldn't turn the led light on or off and no SysRqs or systemd panic buttons would get a responce.

 Once the Wayland session resumes, the keyboard and mouse input start working again. If the Wayland server does not resume at all, the only way to get the system to restart is physically by pressing and holding the power button or the reset button. 

There should be a last line of defense for users when everything has gone wrong under any circumstances and as such, SysRqs should still be used in this scenario.

Comment 1 Toomas 2017-03-07 15:05:30 UTC

I can confirm that the bug exists. I have experienced the same behavior as described in the bug report. Gnome desktop randomly freezes (fortunately not very often). But, if the freeze happens, then the input is completely frozen - not even the SysRq commands work (which seems to be kernel related issue). 

My system parameters:
Fedora 25 x64
kernel 4.9.13-200.fc25.x86_64
nouveau 
systemd-231-14
Wayland
gnome-shell-3.22.3

I have noticed that the freeze happens usually when I try to minimize or change a window and at the same time, some gnome notification (e.g. a message from Spotify).

Comment 2 Dmitry Torokhov 2017-03-11 20:12:02 UTC

I tried to as on free desktop list but I guess the bug is closed and nobody is paying attention. SysRq processing is not done if input device is "grabbed". Peter, do you know if Wayland and the rest of the stack use EVIOCGRAB?

Comment 3 Peter Hutterer 2017-03-12 23:07:14 UTC

I don't think so. libinput doesn't and has no config option to do so, so the only way to get a grab on the fd would be the compositor or logind doing it before passing the fd to libinput.

git grep in mutter doesn't show EVIOCGRAB anywhere and no call to libevdev. git grep in systemd's repo doesn't show it either. git histories for either are empty too.

Nothing else has access to that fd, so the problem must be elsewhere. I wonder if there's some other userspace app that grabs the device? Though you'd think it would then break the device for desktop interaction too, so...
RetroArch's git directory doesn't have any EVIOCGRAB instances either, so.. I don't know, sorry.

Comment 4 Toomas 2017-03-28 14:27:06 UTC

It has been multiple times now that my system freezes and sysrq doesn't do anything. The sad thing is that when I make hard power reset the logs are empty. 
I have noticed that the system freeze is always triggered by some event related to graphical transition. When the system is frozen I can't login via ssh (ping works and nmap shows that the machine has open ssh port). 

My system parameters:
Kernel 4.10.5-200.fc25.x86_64
xorg-x11-drv-nouveau-1.0.13-1
systemd-231-14
gnome-shell-3.22.3-1

Also, I noticed that the problem reveals itself more when gnome-shell uses Wayland.

Comment 5 Antoine Saroufim 2017-03-28 14:33:52 UTC

I think this bug is related to https://bugs.freedesktop.org/show_bug.cgi?id=99900

When Nouveau freezes, even if the kernel did not panic, it stops receiving input.

Comment 6 Joe Breuer 2023-06-06 08:48:14 UTC

Possibly related observation: I'm running LibreELEC.tv on x86_64 hardware, and am trying to debug a suspend/resume issue (different story). This is with kernel 6.3.4 now.

As part of those debugging efforts, I also made the observation that Magic SysRq would NOT work while Kodi is running.

Since I already got bitten by more than enough keyboards that don't properly handle Alt-SysRq for one reason or another, I followed this up with evtest.

evtest would immediately complain that "This device is grabbed by another process". Kodi, obviously, so I got that out of the way, and Magic SysRq would immediately start working from that keyboard.

So, there definitely are user-space 'locking'/'grabbing' situations that also prevent the kernel side of Magic SysRq to work.

Kodi on LibreELEC uses GBM, not wayland, but I presume framebuffer access etc is similar enough. The keyboard is a USB keyboard that shows up under /dev/input/eventX.

I consider Magic SysRq not working in this situation to be a bug. The kernel does see all the input events anyway, and should take the liberty to wrench control due to Magic SysRq, no matter what. Whoever dislikes this, can disable Magic SysRq via procfs/sysctl as usual.