Bugzilla – Bug 1226065
Trackpad does not work after suspend/resume
Last modified: 2024-07-02 06:20:24 UTC
The trackpad on my Framework Gen 11 laptop stopped working after a suspend/resume cycle. The problem turned out to be that I had accidentally enabled secure boot: Jun 06 19:18:01 homelap8.WalkerStreet.info kernel: mousedev: PS/2 mouse device common for all mice Jun 06 19:18:05 homelap8.WalkerStreet.info kernel: Lockdown: vmmouse_detect: raw io port access is restricted; see man kernel_lockdown.7 Disabling secure boot fixes the trackpad problem and eliminates the lockdown log message. It looks like there's some issue in mousedev when secure boot is enabled.
Are you using vmware stuff? The second message indicates that it's in VMware or such. The function checks whether it's in a supported hypervisor and otherwise bail out at the very beginning before hitting this I/O port poking.
(In reply to Takashi Iwai from comment #1) > Are you using vmware stuff? No VMware or any other virtualization. Your comment, though, lends credence to my more recent suspicions that my diagnosis was wrong. What I have noticed over the past few days is that I still have the problem at times. I was busy, so I switched to hibernate, instead of suspend, in /etc/systemd/logind.conf.d: [Login] HandleLidSwitch=hibernate HandleLidSwitchExternalPower=hibernate That resolved the issue, but I'd rather be using suspend. I'm now thinking that the "i8042.reset i8042.nomux=1" that I added to the kernel command line (when the laptop was new and had this problem) no longer has the desired effect. Does that make any sense? Would there be another workaround if so?
Then it means that your machine had already some instability of PS2 connection around suspend/resume in the earlier kernels, but it was worked around by the option. Can you try to pass i8042.reset=1 i8042.nomux options instead?
(In reply to Takashi Iwai from comment #3) > Can you try to pass i8042.reset=1 i8042.nomux options instead? I've made this change to the kernel command line and changed the configuration in /etc/systemd/logind.conf.d back to suspend. So far, so good. Unfortunately, the problem has been intermittent, so I'll let you know how it goes over the next 2-3 days. Thanks!
Sorry, that didn't work. I'm trying "i8042.reset=1 i8042.nomux=1" but that's just a shot in the dark. Any other ideas? By the way, this all started a couple of weeks ago, perhaps with kernel 6.9.x?
If it's 6.9, the kernel should be still available in TW history repo http://donwload.opensuse.org/history/ and could you verify whether it works stable there? Also, an unofficial build for the last 6.9 is found in OBS home:tiwai:kernel:6.9 repo, too, in case it's gone from TW history repo.
Thanks. I've installed kernel-default-6.8.8-1.1, the oldest in TW history. If it works, I'll probe other releases to see where things break. If it doesn't work, I'll try I'll let you know how it goes.
Well it's been a couple of days (including a few sessions of opening and closing the laptop lid 10-15 times) running 6.8.8-1.1 and, later, 6.8.9-1.1 with no problems resuming from a suspend, so it looks like this started with a 6.9 kernel. I'll keep 6.8.9-1.1 around but upgrade to the latest Tumbleweed snapshot (I'm currently on 20240613) to see if anything recent has resolved this problem. Is there's anything I should do to help debug under the assumption that the problem has not been resolved? I'll at least attach log records.
Created attachment 875617 [details] dmesg after booting kernel 6.9.5
Even stranger... After upgrading to TW 20240619, wifi doesn't work under any of the 6.9 kernels I now have installed (6.9.1, 6.9.3, 6.9.5). It does, though, still work under 6.8.9. I've attached dmesg output after booting 6.9.5.
The iwlwifi breakage is a known issue, see bsc#1226544. It's a regression by the latest firmware, appearing only on 6.9.x, as it seems.
And, since this seems like a regression in 6.9, could you report it to the upstream? You can open the report in bugzilla.kernel.org, and better to report as a regression: https://www.kernel.org/doc/html/latest/admin-guide/reporting-regressions.html Feel free to put me (tiwai@suse.de) to Cc.
Sorry for being silent for the past week. I wanted to be able to exhibit the problem (i.e., with a later than 6.8.x kernel) but had wanted to wait until I wouldn't have to worry about managing firmware to use WiFi. I'm now up on snapshot 20240627 with kernel 6.9.6-1-default. In the intervening time, though, I noticed that my BIOS has a setting to disable PS2 emulation, so I disabled it, thinking it might have contributed to the suspend/resume issues I've been having. Now that I'm up with a 6.9.x kernel, I've just opened and closed my laptop several times to test suspend/resume, and I haven't had any problems. I'll wait another day or two to make sure it doesn't come back, but I suspect there's something unusual with the PS2 emulation, rather than an actual fault in the kernel. Does this sound reasonable? I haven't reported this upstream. If disabling PS2 emulation resolves the problem, do you think I still should? Have you heard of others having this problem?
Yes, it makes sense. The log showed that there were another input devices for touchpad, and the incorrectly working PS2 emulation might have interfered that. Could you give the dmesg output after disabling PS2 emulation on BIOS?
Created attachment 875782 [details] Dmesg after disabling PS2 emulation
Thanks. I've attacked the dmesg after disabling PS2 emulation.
FYI, I haven't had any problems for the past few days, so I'm going to assume the PS2 emulation is at fault, unless you find otherwise in the dmesg I attached.
It looks fine, so let's close the entry.