|
Bugzilla – Full Text Bug Listing |
| Summary: | Trackpad does not work after suspend/resume | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | David Walker <David> |
| Component: | Kernel | Assignee: | openSUSE Kernel Bugs <kernel-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | David, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
dmesg after booting kernel 6.9.5
Dmesg after disabling PS2 emulation |
||
|
Description
David Walker
2024-06-07 03:36:36 UTC
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. |