|
Bugzilla – Full Text Bug Listing |
| Summary: | 15.5 upgrade: keyboard and mouse do not respond after resume from suspend to RAM | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Vadim Krevs <vkrevs> |
| Component: | Kernel | Assignee: | openSUSE Kernel Bugs <kernel-bugs> |
| Status: | RESOLVED WORKSFORME | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | opensuse, tiwai, vkrevs |
| Version: | Leap 15.5 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Leap 15.5 | ||
| See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=217752 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Attachment with inxi/dmesg/journalctl/lspci/lsusb outputs for 15.4 and 15.5 kernels | ||
|
Description
Vadim Krevs
2023-07-29 12:12:15 UTC
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. |