Bugzilla – Bug 1213778
15.5 upgrade: keyboard and mouse do not respond after resume from suspend to RAM
Last modified: 2024-03-28 17:34:54 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Build Identifier: This morning I've upgraded my desktop from openSUSE 15.4 to 15.5 via zypper dup. Pretty much the usual pain-free openSUE upgrade - thank you openSUSE team - except for the issue described in this report. All hardware is working perfectly after the upgrade except for a suspend/resume issue with my USB keyboard/mouse. These are connected to the KVM switch built into my Dell U3415W monitor and do not respond after resume from suspend to RAM. The resume itself is triggered by pressing any key on the keyboard so it is curious that mouse and keyboard do not respond once the resume completes. The only way to activate them is to go into the source selection menu in the monitor's OSD KVM switch menu and re-select the active DisplayPort input. After that the system is fully usable. This wasn't an issue before the upgrade in 15.4 - suspend to RAM/resume worked flawlessly. If I boot into 15.5 using the last 15.4 kernel (kernel kernel-default-5.14.21-150400.24.69.1.x86_64), then the issue goes away. So it seems that the issue is with the kernel installed by 15.5 upgrade (kernel-default-5.14.21-150500.55.7.1.x86_64). I've attached a zip file with inxi, lspci, lsusb outputs. Also I ran dmesg and journalctl -r before suspend to RAM/after resume having booted into the 15.4 kernel and 15.5 kernel respectively. Please let me know if you require any additional information or if you'd like me to try another kernel, etc. Reproducible: Always Steps to Reproduce: 1. Upgrade from 15.4 to 15.5. 2. Suspend to RAM 3. Resume by hitting any key on the keyboard. Actual Results: After resume completes, mouse and keyboard connected to the KVM switch built into Dell U3415W monitor do not respond. Expected Results: After resume completes, mouse and keyboard connected to the KVM switch built into Dell U3415W monitor respond as normal (as was the case in 15.4 and in 15.5 when booting into 15.4 kernel).
Created attachment 868501 [details] Attachment with inxi/dmesg/journalctl/lspci/lsusb outputs for 15.4 and 15.5 kernels
We should check both old and new kernels. Could you try the Leap 15.5 GM kernel (kernel-default-5.14.21-150500.53.2) kernel at first, for verifying whether it's a post-GM regression? If the GM kernel shows the same problem, please try the kernel in OBS Kernel:SLE15-SP5 repo. http://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/
Unfortunately, both the Leap 15.5 GM kernel (kernel-default-5.14.21-150500.53.2) kernel and the kernel in OBS Kernel:SLE15-SP5 repo http://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/ (kernel-default-5.14.21-150500.152.g2df8130) also suffer from the same issue. So it looks like a pre-GM regression.
OK, thanks for quick testing. Let's try to narrow down the condition triggering the problem. When you reconnect the USB keyboard, does it start working again? And, it's only about the USB keyboard? If it's connected to a different port without KVM, does it still work after resume? Also, please check with evtest program whether the raw input event device responds, or it also doesn't report any inputs.
(In reply to Takashi Iwai from comment #4) > OK, thanks for quick testing. Let's try to narrow down the condition > triggering the problem. > > When you reconnect the USB keyboard, does it start working again? And, it's only about the USB keyboard? USB Keyboard and USB mouse. When I re-select the DP input in the OSD menu, both the keyboard and mouse start working again. > If it's connected to a different > port without KVM, does it still work after resume? No, it does not. Disconnecting and re-connecting the keyboard makes it work again. > Also, please check with evtest program whether the raw input event device > responds, or it also doesn't report any inputs. Did that. Started evtest with before suspend to RAM. Immediately after resume, the raw input event device does not respond and evtest does not report any inputs.
(In reply to Vadim Krevs from comment #5) > (In reply to Takashi Iwai from comment #4) > > OK, thanks for quick testing. Let's try to narrow down the condition > > triggering the problem. > > > > When you reconnect the USB keyboard, does it start working again? And, it's only about the USB keyboard? > USB Keyboard and USB mouse. When I re-select the DP input in the OSD menu, > both the keyboard and mouse start working again. And disconnecting/reconnecting the keyboard to the KVM port makes both keyboard/mouse work again. > > > If it's connected to a different > > port without KVM, does it still work after resume? > No, it does not. Disconnecting and re-connecting the keyboard makes it work > again. > > > Also, please check with evtest program whether the raw input event device > > responds, or it also doesn't report any inputs. > Did that. Started evtest with before suspend to RAM. Immediately after > resume, the raw input event device does not respond and evtest does not > report any inputs.
OK, and could you test the behavior with the recent kernel, too? Install 6.4.x kernel-default from OBS Kernel:stable:Backport repo http://download.opensuse.org/repositories/Kernel:/stable:/Backport/standard/ and retest with it. Judging from the symptom, it sounds more like some power-saving stuff that kept the thing disconnected.
(In reply to Takashi Iwai from comment #7) > OK, and could you test the behavior with the recent kernel, too? > Install 6.4.x kernel-default from OBS Kernel:stable:Backport repo > > http://download.opensuse.org/repositories/Kernel:/stable:/Backport/standard/ > and retest with it. > > Judging from the symptom, it sounds more like some power-saving stuff that > kept the thing disconnected. Same issue with kernel-default-6.4.7-lp154.3.1.g5da2543.x86_64 from Kernel:/stable:/Backport/standard/. kernel-default-5.14.21-150400.24.69.1.x86_64 is the last kernel version where it works.
Do you use powertop?
(In reply to Michael Hirmke from comment #9) > Do you use powertop? No, not on this desktop pc. The powertop package is installed (probably because it was originally installed by openSUSE 15.2 which was the first version of openSUSE I installed on it), but the systemd's powertop service is disabled by default, just like it was in 15.4.
If the recent upstream kernel also doesn't work, at best, we should report it to the upstream. Care to do that?
(In reply to Takashi Iwai from comment #11) > If the recent upstream kernel also doesn't work, at best, we should report > it to the upstream. Care to do that? https://bugzilla.kernel.org/show_bug.cgi?id=217752
Thanks. Now we may try to figure out which kernel version started showing the problem. There are a few kernel packages in my OBS repos, e.g. home:tiwai:kernel:6.3, home:tiwai:kernel:6.2, ... Those are the last TW kernels of each kernel version, and they also contain "backport" repo that are built for Leap (instead of "standard" for TW). e.g. http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.3/backport/ Could you try one by one and verify which kernel works and which is broken? This will be useful for the upstream. BTW, when you install multiple kernels, it's better to lock the main kernel you're using with "zypper addlock" for avoiding it wiped out. Also, you can increase the number of installable kernels by editing /etc/zypp/zypp.conf and modifying the line to define "multiversion.kernels", e.g. multiversion.kernels = latest,latest-1,latest-2,latest-3,running
(In reply to Takashi Iwai from comment #13) > Thanks. Now we may try to figure out which kernel version started showing > the problem. > > There are a few kernel packages in my OBS repos, e.g. home:tiwai:kernel:6.3, > home:tiwai:kernel:6.2, ... Those are the last TW kernels of each kernel > version, and they also contain "backport" repo that are built for Leap > (instead of "standard" for TW). e.g. > > http://download.opensuse.org/repositories/home:/tiwai:/kernel:/6.3/backport/ > > Could you try one by one and verify which kernel works and which is broken? > This will be useful for the upstream. > > BTW, when you install multiple kernels, it's better to lock the main kernel > you're using with "zypper addlock" for avoiding it wiped out. Also, you can > increase the number of installable kernels by editing /etc/zypp/zypp.conf > and modifying the line to define "multiversion.kernels", e.g. > multiversion.kernels = latest,latest-1,latest-2,latest-3,running I used bisection reduce the number of kernels to test to find the working kernel version in the http://download.opensuse.org/repositories/home:/tiwai:/kernel:/{5.15-6.3}/backport/ repos. kernel-default-5.19.12-lp153.1.1.g95fa5b8.x86_64 - broken kernel-default-5.17.9-lp153.1.1.gc1eda89.x86_64 - broken kernel-default-5.16.16-lp153.1.1.gcdbc159.x86_64 - broken kernel-default-5.15.13-lp153.1.1.g01786ae.x86_64 - works as expected (just like the latest 15.4 kernel).
OK, it's a really old problem, then. The regression was introduced along with 5.16, apparently. After this point, it's tough to figure out the culprit, partly because the problem might be related with several fields like ACPI, USB, input and generic driver PM. The best would be to perform git-bisect between 5.15 and 5.16 kernels. Can you try that?
Apologies for not posting an update for a long while. I had replaced my old AMD Radeon RX 580 with an NVIDIA Geforce RTX 4060Ti card, installed the latest proprietary NVIDIA driver, and the issue went away. Feel free to close this issue.