After upgrading from Fedora 25 to 26, my touchpad fails to resume when I close and re-open the lid. My laptop is a Lenovo Yoga 900 13ISK from a couple years ago. I see these evens in my dmesg log: [ 718.638383] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. [ 718.638402] dpm_run_callback(): i2c_hid_resume+0x0/0xe0 [i2c_hid] returns -11 [ 718.638417] PM: Device i2c-SYNA2B29:00 failed to resume async: error -11 [ 718.638490] PM: resume of devices complete after 5984.723 msecs [ 718.638824] usb 1-7:1.0: rebind failed: -517 [ 718.638833] usb 1-7:1.1: rebind failed: -517 [ 718.639551] PM: resume devices took 5.986 seconds [ 718.639910] PM: Finishing wakeup. Here's the relevant part of the output from libinput-list-devices: Device: Synaptics TM3066-002 Kernel: /dev/input/event15 Group: 6 Seat: seat0, default Size: 87x57mm Capabilities: pointer Tap-to-click: disabled Tap-and-drag: enabled Tap drag lock: disabled Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: n/a Scroll methods: *two-finger edge Click methods: *button-areas clickfinger Disable-w-typing: enabled Accel profiles: none Rotation: n/a Let me know if there's anything you would like me to try or any other output I can provide.
Could you try finding the last working kernel version? Also, could you check if the rawhide nodebug kernels[1] still exposes the issue? It seems the i2c controller is not happy while resuming and prevents the touchpad to come back. A band-aid could be to rmmod hid-rmi and modprobe it again to force a re-enumeration. You might want to remove/re-insert i2c-hid instead if hid-rmi complains about dependencies. [1] https://fedoraproject.org/wiki/RawhideKernelNodebug
I'm not sure how to find the very last working kernel version, but I was running kernel-4.9.12-200.fc25.x86_64 from updates before the upgrade to Fedora 26. I'm running the rawhide nodebug kernel and it is still affected by the problem. Closing my lid and re-opening yields no touchpad until I do the rmmod/modprobe trick. The kernel I'm running right now: [martin@umberto ~]$ uname -a Linux umberto 4.11.0-0.rc1.git3.2.fc27.x86_64 #1 SMP Fri Mar 10 22:15:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux rmmod hid_rmi && modprobe hid_rmi does work around the problem.
Sorry for the delay. There is currently a little bit of discussions upstream regarding hid-rmi and the v4.11. I'd say let's wait for it to settle, I have a feeling this is all related.
*** Bug 1450268 has been marked as a duplicate of this bug. ***
Hello Benjamin, What is the current status of this problem? Do you have a pointer for the discussion you have mentioned on Comment 3? I'm also seeing this problem on a Yoga 900.
> What is the current status of this problem? Do you have a pointer for the discussion you have mentioned on Comment 3? I' ll be reaching out to Synaptics as there is an obvious issue with hid-rmi and resume. https://bugzilla.kernel.org/show_bug.cgi?id=195949 might be related.
> https://bugzilla.kernel.org/show_bug.cgi?id=195949 might be related. Apparently this kernel bz was related to the function F54 being enabled. On Fedora, this is disabled by default, so there must be something else going on :(
Same problem here. Is there any update on this? I'm running kernel 4.11.4-300.fc26.x86_64. See below from journalctl: juni 15 19:01:36 yogafedora.norge.net kernel: ACPI : EC: event unblocked juni 15 19:01:36 yogafedora.norge.net kernel: rtc_cmos 00:04: System wakeup disabled by ACPI juni 15 19:01:36 yogafedora.norge.net kernel: [drm] GuC firmware load skipped juni 15 19:01:36 yogafedora.norge.net kernel: sed_opal:OPAL: Error on step function: 0 with error 8194: Unknown Error juni 15 19:01:36 yogafedora.norge.net kernel: usb 1-7: reset full-speed USB device number 3 using xhci_hcd juni 15 19:01:36 yogafedora.norge.net kernel: usb 1-6: reset high-speed USB device number 2 using xhci_hcd juni 15 19:01:36 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed juni 15 19:01:36 yogafedora.norge.net kernel: [drm] RC6 on juni 15 19:01:36 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed juni 15 19:01:36 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed juni 15 19:01:36 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed juni 15 19:01:36 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed juni 15 19:01:36 yogafedora.norge.net kernel: rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. juni 15 19:01:36 yogafedora.norge.net kernel: dpm_run_callback(): i2c_hid_resume+0x0/0xe0 [i2c_hid] returns -11 juni 15 19:01:36 yogafedora.norge.net kernel: PM: Device i2c-SYNA2B29:00 failed to resume async: error -11 juni 15 19:01:36 yogafedora.norge.net kernel: PM: resume of devices complete after 5209.351 msecs juni 15 19:01:36 yogafedora.norge.net kernel: usb 1-7:1.0: rebind failed: -517 juni 15 19:01:36 yogafedora.norge.net kernel: usb 1-7:1.1: rebind failed: -517 juni 15 19:01:36 yogafedora.norge.net kernel: PM: resume devices took 5.211 seconds juni 15 19:01:36 yogafedora.norge.net kernel: PM: Finishing wakeup.
I installed 4.10.17-200.fc25.x86_64 (no 4.10 builds for F26), and this seems to fix the issue, so it's definitely related to the 4.11 kernel. Hopefully we can get this fixed. I noticed Benjamin Tissoires suggested to remove/re-insert i2c-hid instead of hid-rmi for 4.11, but I would need some assistance to configure and build the kernel myself.
I don't think this issue is related to the F54 issue. But, it is probably related to the switch from the standalone hid-rmi to making hid-rmi a transport for the rmi4 driver. When I compared the two it looks like the rmi4 driver reads the current IRQ mask whereas the hid-rmi driver used to just compute what the IRQ mask should be and write it. It could be that the touchpad is taking some time to resume for some reason. If you have the v4.10 version working can you post the dmesg output after doing a suspend and resume? Also, can you attach the dmesg outpur for v4.11 with i2c_hid debugging enabled after doing a suspend and resume? To enable i2c_hid debugging just run: $ sudo rmmod i2c_hid $ sudo modprobe i2c_hid debug=1 Running these commands with out the debug option will also remove / re-insert i2c-hid which is what Benjamin was suggesting. No need to configure and rebuild the kernel for this work around.
I can't see any reference to i2c-hid at all in the resume with v4.10. Kinda strange, but there seem to be something going on under suspend. I'll post the 4.11 results in a separate post: juni 20 21:43:31 yogafedora.norge.net systemd-sleep[4037]: Suspending system... juni 20 21:45:00 yogafedora.norge.net kernel: PM: Syncing filesystems ... done. juni 20 21:45:00 yogafedora.norge.net kernel: PM: Preparing system for sleep (mem) juni 20 21:45:00 yogafedora.norge.net kernel: Freezing user space processes ... (elapsed 0.002 seconds) done. juni 20 21:45:00 yogafedora.norge.net kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. juni 20 21:45:00 yogafedora.norge.net kernel: PM: Suspending system (mem) juni 20 21:45:00 yogafedora.norge.net kernel: Suspending console(s) (use no_console_suspend to debug) juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: can not read F11 control registers juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: event blocked juni 20 21:45:00 yogafedora.norge.net kernel: PM: suspend of devices complete after 5436.045 msecs juni 20 21:45:00 yogafedora.norge.net kernel: PM: suspend devices took 5.436 seconds juni 20 21:45:00 yogafedora.norge.net kernel: PM: late suspend of devices complete after 15.661 msecs juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: interrupt blocked juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: rmi_read_block: timeout elapsed juni 20 21:45:00 yogafedora.norge.net kernel: hid-rmi 0018:06CB:77C6.0002: can not read F11 control registers juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: event blocked juni 20 21:45:00 yogafedora.norge.net kernel: PM: suspend of devices complete after 5436.045 msecs juni 20 21:45:00 yogafedora.norge.net kernel: PM: suspend devices took 5.436 seconds juni 20 21:45:00 yogafedora.norge.net kernel: PM: late suspend of devices complete after 15.661 msecs juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: interrupt blocked juni 20 21:45:00 yogafedora.norge.net kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI juni 20 21:45:00 yogafedora.norge.net kernel: PM: noirq suspend of devices complete after 29.050 msecs juni 20 21:45:00 yogafedora.norge.net kernel: ACPI: Preparing to enter system sleep state S3 juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: EC stopped juni 20 21:45:00 yogafedora.norge.net kernel: PM: Saving platform NVS memory juni 20 21:45:00 yogafedora.norge.net kernel: Disabling non-boot CPUs ... juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: CPU 1 is now offline juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: CPU 2 is now offline juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: CPU 3 is now offline juni 20 21:45:00 yogafedora.norge.net kernel: [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -31579631. Restoring juni 20 21:45:00 yogafedora.norge.net kernel: ACPI: Low-level resume complete juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: EC started juni 20 21:45:00 yogafedora.norge.net kernel: PM: Restoring platform NVS memory juni 20 21:45:00 yogafedora.norge.net kernel: Suspended for 81.639 seconds juni 20 21:45:00 yogafedora.norge.net kernel: Enabling non-boot CPUs ... juni 20 21:45:00 yogafedora.norge.net kernel: x86: Booting SMP configuration: juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 juni 20 21:45:00 yogafedora.norge.net kernel: [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -599642361 CPU1: 0 juni 20 21:45:00 yogafedora.norge.net kernel: cache: parent cpu1 should not be sleeping juni 20 21:45:00 yogafedora.norge.net kernel: microcode: sig=0x406e3, pf=0x40, revision=0x8a juni 20 21:45:00 yogafedora.norge.net kernel: CPU1 is up juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: Booting Node 0 Processor 2 APIC 0x1 juni 20 21:45:00 yogafedora.norge.net kernel: [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -599642361 CPU2: 0 juni 20 21:45:00 yogafedora.norge.net kernel: cache: parent cpu2 should not be sleeping juni 20 21:45:00 yogafedora.norge.net kernel: microcode: sig=0x406e3, pf=0x40, revision=0xba juni 20 21:45:00 yogafedora.norge.net kernel: CPU2 is up juni 20 21:45:00 yogafedora.norge.net kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3 juni 20 21:45:00 yogafedora.norge.net kernel: [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -599642361 CPU3: 0 juni 20 21:45:00 yogafedora.norge.net kernel: cache: parent cpu3 should not be sleeping juni 20 21:45:00 yogafedora.norge.net kernel: CPU3 is up juni 20 21:45:00 yogafedora.norge.net kernel: ACPI: Waking up from system sleep state S3 juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: interrupt unblocked juni 20 21:45:00 yogafedora.norge.net kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI juni 20 21:45:00 yogafedora.norge.net kernel: PM: noirq resume of devices complete after 26.695 msecs juni 20 21:45:00 yogafedora.norge.net kernel: PM: early resume of devices complete after 33.245 msecs juni 20 21:45:00 yogafedora.norge.net kernel: ACPI : EC: event unblocked juni 20 21:45:00 yogafedora.norge.net kernel: rtc_cmos 00:04: System wakeup disabled by ACPI juni 20 21:45:00 yogafedora.norge.net kernel: [drm] GuC firmware load skipped juni 20 21:45:00 yogafedora.norge.net kernel: usb 1-7: reset full-speed USB device number 5 using xhci_hcd juni 20 21:45:00 yogafedora.norge.net kernel: usb 1-6: reset high-speed USB device number 2 using xhci_hcd juni 20 21:45:00 yogafedora.norge.net kernel: PM: resume of devices complete after 806.798 msecs juni 20 21:45:00 yogafedora.norge.net kernel: usb 1-7:1.0: rebind failed: -517 juni 20 21:45:00 yogafedora.norge.net kernel: usb 1-7:1.1: rebind failed: -517 juni 20 21:45:00 yogafedora.norge.net kernel: PM: resume devices took 0.808 seconds
Created attachment 1289896 [details] dmesg print of resume under v4.11
*** Bug 1459794 has been marked as a duplicate of this bug. ***
Fedora 26 Beta + Latest Updates, following workaround helps sudo rmmod hid_rmi && sudo modprobe hid_rmi
Created attachment 1293254 [details] Kernel log from the last good commit
Created attachment 1293255 [details] Kernel log from the first bad commit in a success case
Created attachment 1293256 [details] Kernel log from the first bad commit in a failure case
(In reply to Andrew Duggan from comment #10) > I don't think this issue is related to the F54 issue. But, it is probably > related to the switch from the standalone hid-rmi to making hid-rmi a > transport for the rmi4 driver. When I compared the two it looks like the > rmi4 driver reads the current IRQ mask whereas the hid-rmi driver used to > just compute what the IRQ mask should be and write it. > You are right, I checked that the following commit is bad: commit 0b2c7a897378f11e86c0b3d426bf678b759c6a8d Author: Andrew Duggan <aduggan> Date: Thu Jan 5 09:48:58 2017 +0100 HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4 The Synaptics RMI4 driver provides support for RMI4 devices. Instead of duplicating the RMI4 processing code, make hid-rmi a transport driver and register it with the Synaptics RMI4 core. Signed-off-by: Andrew Duggan <aduggan> Signed-off-by: Benjamin Tissoires <benjamin.tissoires> Signed-off-by: Jiri Kosina <jkosina> While its parent is good: commit da2875673660c114dc7d65edcd1f97023d0ed624 Merge: 74e5c265a495 143fca77cce9 Author: Linus Torvalds <torvalds> Date: Mon Jan 2 12:42:50 2017 -0800 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid Pull HID fixes from Jiri Kosina: - regression fix (caused by me applying a wrong version of patch) for sensor-hub driver, from Srinivas Pandruvada - hid-sony fixes (mostly related to DS4 device) from Roderick Colenbrander - three device-specific quirks-fixes from Alex Wood, Brendan McGrath and Marcel Hasler * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: sensor-hub: Move the memset to sensor_hub_get_feature() HID: usbhid: Add quirk for Mayflash/Dragonrise DolphinBar. HID: usbhid: Add quirk for the Futaba TOSD-5711BB VFD HID: sony: Ignore DS4 dongle reports when no device is connected HID: sony: Use DS4 MAC address as unique identifier on USB HID: sony: Fix error handling bug when touchpad registration fails HID: asus: Fix keyboard support > It could be that the touchpad is taking some time to resume for some reason. > If you have the v4.10 version working can you post the dmesg output after > doing a suspend and resume? > > Also, can you attach the dmesg outpur for v4.11 with i2c_hid debugging > enabled after doing a suspend and resume? > I have attached dmesg logs for the good commit, and for the bad commit both when it fails, and when it does not fail. In all cases I have done the following modification to prevent flooding the log: --- a/drivers/hid/i2c-hid/i2c-hid.c +++ b/drivers/hid/i2c-hid/i2c-hid.c @@ -62,7 +62,7 @@ MODULE_PARM_DESC(debug, "print a lot of debug information"); #define i2c_hid_dbg(ihid, fmt, arg...) \ do { \ - if (debug) \ + if (debug && !strcmp(ihid->client->name, "SYNA2B29:00")) \ dev_printk(KERN_DEBUG, &(ihid)->client->dev, fmt, ##arg); \ } while (0)
Created attachment 1293399 [details] Resume debugging patch
Thanks for the logs. It looks like the touchpad's firmware is correctly sending the reply: [ 125.347304] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 42 00 01 00 04 00 00 0c cc 06 74 04 0f 19 00 00 00 00 00 [ 125.352198] i2c_hid i2c-SYNA2B29:00: input: 2a 00 0b 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... [ 126.379614] hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout elapsed But, for some reason it is not being received by hid-rmi. The patch I uploaded adds some debugging statements which hopefully will point to where the reply is getting dropped. Can I get a log with this patch applied and i2c_hid debugging turned on?
(In reply to Andrew Duggan from comment #20) > Thanks for the logs. It looks like the touchpad's firmware is correctly > sending the reply: > [ 125.347304] i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=25 00 17 00 > 0a 00 42 00 01 00 04 00 00 0c cc 06 74 04 0f 19 00 00 00 00 00 > [ 125.352198] i2c_hid i2c-SYNA2B29:00: input: 2a 00 0b 01 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 > ... > [ 126.379614] hid-rmi 0018:06CB:77C6.0002: rmi_hid_read_block: timeout > elapsed > > But, for some reason it is not being received by hid-rmi. The patch I > uploaded adds some debugging statements which hopefully will point to where > the reply is getting dropped. Can I get a log with this patch applied and > i2c_hid debugging turned on? How do I apply this patch?
Created attachment 1297335 [details] Kernel log with hid-rmi debug resume in a success case
Created attachment 1297336 [details] Kernel log with hid-rmi debug resume in a failure case
I have attached logs with Andrew's hid-rmi resume debugging patch on both failure (tp does not work after resume) and success (tp works after resume) cases.
Hey! This new machine (Razer Blade Stealth, shows the same issue) has sure been an adventure... So there's some interesting things I'd like to note here that I've noticed. Mainly: - This bug started on f26. Literally f26. When I was running F25 on a 4.12.0-rc7 rawhide kernel (with debugging options hacked out and one patch to fix jumping cursors added) I never had any issues with the touchpad resuming. Since updating to F26, I now see these issues using the exact same kernel build, along with the 4.12.1 (same deal with the config options and patches) build I just made. - Not all suspend paths seem to trigger this. I don't know exactly which ones do, all I know are the steps I've managed to take that make it resume correctly and don't: - If I'm in gnome-shell and I suspend the laptop by pressing the power button or sudo systemctl suspend, the touchpad resumes normally - If I'm in gnome-shell and I close the lid to suspend the machine then the touchpad doesn't resume normally - To make sure it wasn't acpi lid interactions (that would really suck ): I tried going into a tty and suspending from there without closing the lid just by using sudo systemctl suspend. Luckily, the touchpad never resumes properly when suspending from a tty regardless of the lid state. Maybe something with these codepaths is changing the order that the devices get resumed in? I will have to play around with the pm_trace options and see if I notice anything different between the working suspend cases and the non-working ones...
That is interesting. Based on the logs which João (thanks!) posted it looks like when the resume fails it is because the I2C_HID_STARTED bit is not set in i2c-hid's flags. This then prevents the reply input report from being sent to hid-rmi which causes it to timeout waiting for the reply. I would look to see if one cause would be i2c_hid_close() is being called on suspend, but i2c_hid_open() is not being called on resume. And if i2c_hid_open() is being called is there something which is preventing the I2C_HID_STARTED bit from being set. Maybe the value of hid->open?
a-ha. At first I thought the different suspend/resume paths that I found did and didn't work were coincidence, but it turns out they were hinting at the real problem the whole time :). It looks like hid-rmi makes the mistake of never actually opening up the hid device on suspend/resume. In fact, it looks like suspend/resume may have been broken with this driver for quite some time now. The only reason we never saw any issues with it before was because for whatever reason, userspace would keep the /dev/input/eventX node for the device open. Doing this allowed the hid device to turn on by the time the RMI driver tries to resume, causing suspend/resume to work. When F26 happened some code must have changed in userspace, possibly systemd, that caused us to close these input nodes before suspending. So we'd try to resume, HID device wouldn't respond, things timed out, etc. As a little proof of this, I'll upload a dmesg from my machine with dump_stack() calls inserted on the hid_hw_open()/hid_hw_close() callbacks. You'll notice as a result of us closing the input event node, the hid device goes down as well before we suspend/resume. This didn't seem to happen on the working s/r codepaths I found earlier. Additionally, I've fired up a koji build for F26's kernel with the fix applied. Would all of the people here affected by this bug try this RPM and let me know whether or not it fixes your issue? https://koji.fedoraproject.org/koji/taskinfo?taskID=20685583
Created attachment 1302952 [details] Lyude's dmesg of broken s/r - razer blade stealth
I've got the kernel from the koji build installed and running. So far I've suspended twice and the touchpad came back alive both times, so that's promising.
Created attachment 1303885 [details] jprvita's kernel log debugging i2c_hid_{open,close}
I've see the same scenario as Lyude on my Yoga 900. Just attached the output during suspend-resume with the following additional debug messages: --- a/drivers/hid/i2c-hid/i2c-hid.c +++ b/drivers/hid/i2c-hid/i2c-hid.c @@ -800,13 +800,20 @@ static int i2c_hid_open(struct hid_device *hid) int ret = 0; mutex_lock(&i2c_hid_open_mut); + i2c_hid_dbg(ihid, "%s: hid->open=%d\n", __func__, hid->open); if (!hid->open++) { ret = pm_runtime_get_sync(&client->dev); if (ret < 0) { + i2c_hid_dbg(ihid, "%s: pm_runtime_get_sync failed\n", __func__); + i2c_hid_dbg(ihid, "%s: NOT setting I2C_HID_STARTED\n", __func__); hid->open--; goto done; } + i2c_hid_dbg(ihid, "%s: setting I2C_HID_STARTED\n", __func__); set_bit(I2C_HID_STARTED, &ihid->flags); + } else { + i2c_hid_dbg(ihid, "%s: hid->open %d != 1\n", __func__, hid->open); + i2c_hid_dbg(ihid, "%s: NOT setting I2C_HID_STARTED\n", __func__); } done: mutex_unlock(&i2c_hid_open_mut); @@ -823,11 +830,16 @@ static void i2c_hid_close(struct hid_device *hid) * care about */ mutex_lock(&i2c_hid_open_mut); + i2c_hid_dbg(ihid, "%s: hid->open=%d\n", __func__, hid->open); if (!--hid->open) { + i2c_hid_dbg(ihid, "%s: clearing I2C_HID_STARTED\n", __func__); clear_bit(I2C_HID_STARTED, &ihid->flags); /* Save some power */ pm_runtime_put(&client->dev); + } else { + i2c_hid_dbg(ihid, "%s: hid->open %d != 0\n", __func__, hid->open); + i2c_hid_dbg(ihid, "%s: NOT clearing I2C_HID_STARTED\n", __func__); } mutex_unlock(&i2c_hid_open_mut); } Lyude, can you provide a patch for testing? I'm not running Fedora here.
https://patchwork.kernel.org/patch/9858267/ The patch should be here. It will probably soon be replaced by one that just adds some calls to the appropriate functions in RMI4's transport layer as opposed to doing them explicitly in the resume path, but it should fix your problem for the time being.
kernel-4.12.4-300.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-14ad2c5d17
kernel-4.12.4-300.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-14ad2c5d17
I'm seeing what are possibly related issues with kernel-4.12.5-200.fc25, but the net result in my case is that I can no longer suspend. This is filed as bug 1480602. Though suspension fails, the trackpad stops working, as discussed here, and also, it's related to rmi4, it seems, e.g. "[ 2418.978307] rmi4_f01 rmi4-00.fn01: Suspend failed with code -6."
With 4.12.5-300.fc26, Lenovo Thinkpad X240, I had working touchpad on first boot, successful suspend, but on resume the touchpad is broken, and the subsequent suspend now fails. Do you want to track this here, or in David's bug 1480602? At boot: [ 10.897179] rmi4_smbus 9-002c: registering SMbus-connected sensor [ 10.933383] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2749-001, fw id: 0 [ 10.971760] input: Synaptics TM2749-001 as /devices/rmi4-00/input/input21 [ 11.252674] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [ 11.348182] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 11.408726] input: TPPS/2 IBM TrackPoint as /devices/rmi4-00/rmi4-00.fn03/serio3/input/input22 I don't see anything logged by rmi4* during the resume. At suspend I now get: [ 753.972069] rmi4_smbus 9-002c: failed to get SMBus version number! [ 753.972341] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. [ 753.972628] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6. [ 753.972629] rmi4_f01 rmi4-00.fn01: Resume failed with code -6. [ 753.972630] rmi4_physical rmi4-00: Failed to suspend functions: -6 [ 753.972631] rmi4_smbus 9-002c: Failed to resume device: -6 [ 753.973797] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
I'm having the same (and other) wayland-related problems on Fedora 27, so this is definitely still an issue. The Xorg Session in 27 is broken with GNOME 3.26. In addition to the touchpad problem, the computer freezes up sometimes if the display gets turns off by GNOME's power management. At least, I think it's frozen. Since the display won't turn back on, holding down the power key and doing a hard reset is the only way to make the computer usable again. So I've switched to KDE on X because it seems to work. Wayland, IMO, is not production-ready. It's seriously alarming that several mainstream distributions have declared that it will be the default user experience.
(In reply to Ryan Farmer from comment #37) > I'm having the same (and other) wayland-related problems on Fedora 27, so > this is definitely still an issue. > > The Xorg Session in 27 is broken with GNOME 3.26. > > In addition to the touchpad problem, the computer freezes up sometimes if > the display gets turns off by GNOME's power management. At least, I think > it's frozen. Since the display won't turn back on, holding down the power > key and doing a hard reset is the only way to make the computer usable > again. > > So I've switched to KDE on X because it seems to work. > > Wayland, IMO, is not production-ready. It's seriously alarming that several > mainstream distributions have declared that it will be the default user > experience. Wayland is not the cause of this problem, the fact that it happens on wayland is just a coincidence of gnome-shell/systemd closing the input fd before suspending, causing the touchpad to hit a codepath where it drops it's only refcount and doesn't manage to resume correctly (and yes, this is valid behaviour and isn't something input drivers should be choking on). Additionally, there has been a patch that fixes this in Fedora 26's kernel for quite a while now. I know it works because otherwise I wouldn't be able to resume my laptop at all ;). We're currently working on getting this patch upstream as well. Please take a look at the patch I linked to in comment 32.
kernel-4.13.3-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-23dba9fb5d
kernel-4.13.3-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-23dba9fb5d
kernel-4.13.3-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
4.13.3-200.fc26 doesn't address any of my issues. I assume the Fedora 27 equivalent would be no different.
4.13.4-200.fc26 still address the issue. I have a X240 with the same problem. Still getting this message when the device wake up: [ 1719.321885] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6). Also, sometimes I'm getting a strange behavior with the cursor. Rolling using two fingers is like clicking a thousand times with the middle button. This is also a message i'm getting from kernel when the device wake up: [ 1719.302583] usb 2-7:1.0: rebind failed: -517 [ 1719.302589] usb 2-7:1.1: rebind failed: -517
Still an issue with kernel 4.13.6.
Still an issue with kernel 4.15.6-300.fc27.x86_64 with Thinkpad T460p. [...] [12887.302346] rmi4_smbus 11-002c: failed to get SMBus version number! [12887.302353] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. [12887.302360] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16. [12887.302362] rmi4_f01 rmi4-00.fn01: Resume failed with code -16. [12887.302365] rmi4_physical rmi4-00: Failed to suspend functions: -16 [12887.302367] rmi4_smbus 11-002c: Failed to resume device: -16 [12887.302688] usb 1-7:1.0: rebind failed: -517 [12887.302692] usb 1-7:1.1: rebind failed: -517 [12887.302725] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16). [12887.302756] rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts! [...]
I believe I have the same problem as in comment #45 I close the lid of Lenovo ThinkPad T460p, once I open again keyboard is working but trackpad is NOT working dmesg output extract: ... [ 243.092302] usb 1-7: reset full-speed USB device number 3 using xhci_hcd [ 243.220689] rmi4_smbus 10-002c: failed to get SMBus version number! [ 243.220696] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. [ 243.220704] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16. [ 243.220706] rmi4_f01 rmi4-00.fn01: Resume failed with code -16. [ 243.220709] rmi4_physical rmi4-00: Failed to suspend functions: -16 [ 243.220712] rmi4_smbus 10-002c: Failed to resume device: -16 [ 243.220746] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16). [ 243.220780] rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts! [ 243.333304] usb 1-6: reset full-speed USB device number 2 using xhci_hcd [ 243.462375] usb 1-7:1.0: rebind failed: -517 [ 243.462382] usb 1-7:1.1: rebind failed: -517 [ 243.462707] PM: resume devices took 0.845 seconds [ 243.462915] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! [ 243.462928] psmouse: probe of serio3 failed with error -1 ...
still happening with 4.15.17-300.fc27.x86_64 on a Lenovo X1 Carbon 20A7008JGE [ 9951.458361] usb 1-1.5: reset full-speed USB device number 3 using ehci-pci [ 9951.552149] rmi4_smbus 10-002c: failed to get SMBus version number! [ 9951.552611] rmi4_physical rmi4-01: rmi_driver_reset_handler: Failed to read current IRQ mask. [ 9951.553066] rmi4_f01 rmi4-01.fn01: Failed to restore normal operation: -6. [ 9951.553070] rmi4_f01 rmi4-01.fn01: Resume failed with code -6. [ 9951.553073] rmi4_physical rmi4-01: Failed to suspend functions: -6 [ 9951.553077] rmi4_smbus 10-002c: Failed to resume device: -6 [ 9951.553402] PM: resume devices took 0.734 seconds [ 9951.553632] OOM killer enabled. [ 9951.553633] Restarting tasks ... [ 9951.553897] rmi4_f03 rmi4-01.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6). [ 9951.559189] rmi4_physical rmi4-01: rmi_driver_clear_irq_bits: Failed to change enabled interrupts! [ 9951.560877] done. [ 9951.575076] rmi4_physical rmi4-01: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
(In reply to d.labriola from comment #45) > Still an issue with kernel 4.15.6-300.fc27.x86_64 with Thinkpad T460p. > > [...] > [12887.302346] rmi4_smbus 11-002c: failed to get SMBus version number! The t460p should not be using rmi4 anymore (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/input/mouse?h=linux-4.15.y&id=9f30ff6fa1a4b6075309163af33ca4d59ba8c9ae has been included in v4.15.10). So please upgrade and report if it is still not working. (In reply to Phil from comment #47) > still happening with 4.15.17-300.fc27.x86_64 on a Lenovo X1 Carbon 20A7008JGE > > [ 9951.458361] usb 1-1.5: reset full-speed USB device number 3 using ehci-pci > [ 9951.552149] rmi4_smbus 10-002c: failed to get SMBus version number! I guess the X1 Carbon 2nd gen suffers from the same issue. Please provide a full dmesg containing the suspend/resume issue so I can see if there is something wrong and similar to the t460p.
Created attachment 1427066 [details] dmesg on a X1 Carbon 20A7008JGE usually when this happens I open a terminal and run 'rmmod rmi_smbus ; insmod rmi_smbus' to get the touchpad working again
Same happening here... after closing and reopening the lid. +++ System Info System = LENOVO ThinkPad X1 Yoga 3rd 20LDCTO1WW BIOS = N25ET26W (1.12 ) Release = "Fedora release 28 (Twenty Eight)" Kernel = 4.16.3-301.fc28.x86_64 #1 SMP Mon Apr 23 21:59:58 UTC 2018 x86_64 +++ Debug: # evemu-record Available devices: /dev/input/event0: Sleep Button /dev/input/event1: Lid Switch /dev/input/event2: Power Button /dev/input/event3: AT Translated Set 2 keyboard /dev/input/event4: Lenovo ThinkPad Thunderbolt 3 Dock USB Audio /dev/input/event5: SynPS/2 Synaptics TouchPad /dev/input/event6: Wacom Pen and multitouch sensor Finger /dev/input/event7: Wacom Pen and multitouch sensor Pen /dev/input/event8: TPPS/2 Elan TrackPoint /dev/input/event9: Video Bus /dev/input/event10: ThinkPad Extra Buttons /dev/input/event11: HDA Intel PCH Mic /dev/input/event12: HDA Intel PCH Headphone /dev/input/event13: HDA Intel PCH HDMI/DP,pcm=3 /dev/input/event14: HDA Intel PCH HDMI/DP,pcm=7 /dev/input/event15: HDA Intel PCH HDMI/DP,pcm=8 /dev/input/event16: HDA Intel PCH HDMI/DP,pcm=9 /dev/input/event17: HDA Intel PCH HDMI/DP,pcm=10 /dev/input/event18: Integrated Camera: Integrated C Select the device event number [0-18]: 1 # EVEMU 1.3 # Kernel: 4.16.3-301.fc28.x86_64 # DMI: dmi:bvnLENOVO:bvrN25ET26W(1.12):bd04/16/2018:svnLENOVO:pn20LDCTO1WW:pvrThinkPadX1Yoga3rd:rvnLENOVO:rn20LDCTO1WW:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: # Input device name: "Lid Switch" # Input device ID: bus 0x19 vendor 0000 product 0x05 version 0000 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 5 (EV_SW) # Event code 0 (SW_LID) # State 0 # Properties: N: Lid Switch I: 0019 0000 0005 0000 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 00 00 00 00 00 00 00 00 B: 05 01 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ E: 0.000001 0005 0000 0001 # EV_SW / SW_LID 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 7.685585 0005 0000 0000 # EV_SW / SW_LID 0 E: 7.685585 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +7685ms Anything else i can provide or test? Thx, Max
I have the same issue as Phil, with an X1C 6th, model 20KGS03800. issue suspend command, then: [11537.617558] psmouse serio1: Failed to disable mouse on isa0060/serio1 sleep ... resume: [11538.532430] psmouse serio1: Failed to deactivate mouse on isa0060/serio1: -5 [11538.740916] usb 1-8: reset high-speed USB device number 3 using xhci_hcd [11538.778250] rmi4_smbus 6-002c: failed to get SMBus version number! [11538.821960] rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask. [11538.865658] rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6. [11538.865662] rmi4_f01 rmi4-00.fn01: Resume failed with code -6. [11538.865665] rmi4_physical rmi4-00: Failed to suspend functions: -6 [11538.865668] rmi4_smbus 6-002c: Failed to resume device: -6 [11538.909333] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6). [11538.953020] rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts! Just out of curiosity, what meaning do the rmi driver error codes have? E.g. [11673.175068] rmi4_f12 rmi4-01.fn12: Failed to read object data. Code: -6. Is that number the number of irqs tried? I can manually reconnect both touchpad and trackpoint via echo -n "{none,reconnect}" | sudo tee /sys/bus/serio/devices/serio1/drvctl